* [PATCH] ARM: dts: at91: sama5d2 Xplained: add QSPI0 + SPI NOR memory nodes
From: Tudor.Ambarus @ 2018-12-10 17:15 UTC (permalink / raw)
To: Nicolas.Ferre, alexandre.belloni, Ludovic.Desroches, robh+dt,
mark.rutland, Cyrille.Pitchen
Cc: devicetree, Tudor.Ambarus, linux-kernel, linux-spi,
boris.brezillon, broonie, linux-mtd, linux-arm-kernel
From: Cyrille Pitchen <cyrille.pitchen@microchip.com>
This patch configures the QSPI0 controller pin muxing and declares
a jedec,spi-nor memory.
sama5d2 Xplained RevB and RevC use the Macronix MX25L25673G flash
memory which advertises a maximum frequency of 80MHz for Quad IO
Fast Read. Set the spi-max-frequency to 80MHz knowing that actually
the QSPI drver will set the SPI bus clock to 166MHz / 3 = 55.3MHz.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@microchip.com>
[tudor.ambarus@microchip.com:
- drop partitions,
- add spi-rx/tx-bus-width
- change spi-max-frequency to match the 80MHz limit advertised by
MX25L25673G for Quad IO Fast Read,
- reword commit message and subject.]
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 31 +++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 518e2b095ccf..171bc82cfbbf 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -108,6 +108,21 @@
};
apb {
+ qspi0: spi@f0020000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_qspi0_default>;
+ /* status = "okay"; */ /* conflict with sdmmc1 */
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <80000000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ m25p,fast-read;
+ };
+ };
+
spi0: spi@f8000000 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_spi0_default>;
@@ -485,6 +500,22 @@
bias-disable;
};
+ pinctrl_qspi0_default: qspi0_default {
+ sck_cs {
+ pinmux = <PIN_PA22__QSPI0_SCK>,
+ <PIN_PA23__QSPI0_CS>;
+ bias-disable;
+ };
+
+ data {
+ pinmux = <PIN_PA24__QSPI0_IO0>,
+ <PIN_PA25__QSPI0_IO1>,
+ <PIN_PA26__QSPI0_IO2>,
+ <PIN_PA27__QSPI0_IO3>;
+ bias-pull-up;
+ };
+ };
+
pinctrl_sdmmc0_default: sdmmc0_default {
cmd_data {
pinmux = <PIN_PA1__SDMMC0_CMD>,
--
2.9.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* mvebu: how to determine the address of the internal register window
From: Uwe Kleine-König @ 2018-12-10 17:09 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: kernel, linux-arm-kernel
[-- Attachment #1.1.1: Type: text/plain, Size: 747 bytes --]
Hello,
using barebox on an mvebu machine the internal register window is moved
from 0xd0000000 to 0xf1000000. Compared to U-Boot the PCI Express BAR0
Internal Registers (on Armada 370: 0x40010 and 0x80010, on Armada XP a
few more) are not fixed which makes accessing pci devices fail. Instead
of letting barebox fix this up I'd like to make Linux ensure the
register is configured correctly.
I think the right place for that is mvebu_pcie_setup_wins which needs to do
mvebu_writel(port, intregoffset, PCIE_BAR_LO_OFF(0));
I wonder however how I should determine the actual value to write here.
I didn't find a function that exports the offset of the internal
register window. Do you have a hint for me?
Best regards
Uwe
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 5/7] arm64: mm: Prevent mismatched 52-bit VA support
From: Steve Capper @ 2018-12-10 17:08 UTC (permalink / raw)
To: Will Deacon
Cc: ard.biesheuvel@linaro.org, Catalin Marinas, Suzuki Poulose,
linux-mm@kvack.org, jcm@redhat.com, nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210165538.GA26756@capper-debian.cambridge.arm.com>
On Mon, Dec 10, 2018 at 04:55:38PM +0000, Steve Capper wrote:
> On Mon, Dec 10, 2018 at 04:18:26PM +0000, Will Deacon wrote:
> > On Mon, Dec 10, 2018 at 04:04:02PM +0000, Steve Capper wrote:
> > > On Mon, Dec 10, 2018 at 01:36:40PM +0000, Will Deacon wrote:
> > > > On Fri, Dec 07, 2018 at 05:28:58PM +0000, Suzuki K Poulose wrote:
> > > > > On 07/12/2018 15:26, Will Deacon wrote:
> > > > > > On Fri, Dec 07, 2018 at 10:47:57AM +0000, Suzuki K Poulose wrote:
> > > > > > > On 12/06/2018 10:50 PM, Steve Capper wrote:
> > > > > > > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > > > > > > > index f60081be9a1b..58fcc1edd852 100644
> > > > > > > > --- a/arch/arm64/kernel/head.S
> > > > > > > > +++ b/arch/arm64/kernel/head.S
> > > > > > > > @@ -707,6 +707,7 @@ secondary_startup:
> > > > > > > > /*
> > > > > > > > * Common entry point for secondary CPUs.
> > > > > > > > */
> > > > > > > > + bl __cpu_secondary_check52bitva
> > > > > > > > bl __cpu_setup // initialise processor
> > > > > > > > adrp x1, swapper_pg_dir
> > > > > > > > bl __enable_mmu
> > > > > > > > @@ -785,6 +786,31 @@ ENTRY(__enable_mmu)
> > > > > > > > ret
> > > > > > > > ENDPROC(__enable_mmu)
> > > > > > > > +ENTRY(__cpu_secondary_check52bitva)
> > > > > > > > +#ifdef CONFIG_ARM64_52BIT_VA
> > > > > > > > + ldr_l x0, vabits_user
> > > > > > > > + cmp x0, #52
> > > > > > > > + b.ne 2f > +
> > > > > > > > + mrs_s x0, SYS_ID_AA64MMFR2_EL1
> > > > > > > > + and x0, x0, #(0xf << ID_AA64MMFR2_LVA_SHIFT)
> > > > > > > > + cbnz x0, 2f
> > > > > > > > +
> > > > > > > > + adr_l x0, va52mismatch
> > > > > > > > + mov w1, #1
> > > > > > > > + strb w1, [x0]
> > > > > > > > + dmb sy
> > > > > > > > + dc ivac, x0 // Invalidate potentially stale cache line
> > > > > > >
> > > > > > > You may have to clear this variable before a CPU is brought up to avoid
> > > > > > > raising a false error message when another secondary CPU doesn't boot
> > > > > > > for some other reason (say granule support) after a CPU failed with lack
> > > > > > > of 52bitva. It is really a crazy corner case.
> > > > > >
> > > > > > Can't we just follow the example set by the EL2 setup in the way that is
> > > > > > uses __boot_cpu_mode? In that case, we only need one variable and you can
> > > > > > detect a problem by comparing the two halves.
> > > > >
> > > > > The only difference here is, the support is bolted at boot CPU time and hence
> > > > > we need to verify each and every CPU, unlike the __boot_cpu_mode where we
> > > > > check for mismatch after the SMP CPUs are brought up. If we decide to make
> > > > > the choice later, something like that could work. The only caveat is the 52bit
> > > > > kernel VA will have to do something like the above.
> > > >
> > > > So looking at this a bit more, I think we're better off repurposing the
> > > > upper bits of the early boot status word to contain a reason code, rather
> > > > than introducing new variables for every possible mismatch.
> > > >
> > > > Does the untested diff below look remotely sane to you?
> > > >
> > > > Will
> > > >
> > >
> > > Thanks Will,
> > > This looks good to me, I will test now and fold this into a patch.
> >
> > Cheers, Steve. Testing would be handy, but don't worry about respinning the
> > patches as I'm already on top of this and hope to push this out later today.
> >
>
> Thanks Will,
> This looks good to me so FWIW:
> Tested-by: Steve Capper <steve.capper@arm.com>
>
> (for both the 52-bit VA mismatch and 64KB granule not supported cases
> using the model).
>
> The only small issue I see is that if subsequent CPUs aren't brought
> online (because they don't exist in the model) then the error reason is
> repeated.
>
> I'll dig into this.
>
I think __early_cpu_boot_status needs to be reset at the beginning of
__cpu_up before the secondary is booted. Testing a check for this now.
Cheers,
--
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4] cpuidle: big.LITTLE: fix refcount leak
From: Daniel Lezcano @ 2018-12-10 17:00 UTC (permalink / raw)
To: Yangtao Li, lorenzo.pieralisi, rjw
Cc: linux-kernel, linux-arm-kernel, linux-pm
In-Reply-To: <20181210162641.21029-1-tiny.windzz@gmail.com>
On 10/12/2018 17:26, Yangtao Li wrote:
> of_find_node_by_path() acquires a reference to the node
> returned by it and that reference needs to be dropped by its caller.
> bl_idle_init() doesn't do that, so fix it.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> changes in v4:
> -update tile
> -refactor code,suggested by Daniel
> ---
> drivers/cpuidle/cpuidle-big_little.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/cpuidle-big_little.c b/drivers/cpuidle/cpuidle-big_little.c
> index db2ede565f1a..b44476a1b7ad 100644
> --- a/drivers/cpuidle/cpuidle-big_little.c
> +++ b/drivers/cpuidle/cpuidle-big_little.c
> @@ -167,6 +167,7 @@ static int __init bl_idle_init(void)
> {
> int ret;
> struct device_node *root = of_find_node_by_path("/");
> + const struct of_device_id *match_id;
>
> if (!root)
> return -ENODEV;
> @@ -174,7 +175,11 @@ static int __init bl_idle_init(void)
> /*
> * Initialize the driver just for a compliant set of machines
> */
> - if (!of_match_node(compatible_machine_match, root))
> + match_id = of_match_node(compatible_machine_match, root);
> +
> + of_node_put(root);
> +
> + if (!match_id)
> return -ENODEV;
>
> if (!mcpm_is_available())
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 5/7] arm64: mm: Prevent mismatched 52-bit VA support
From: Steve Capper @ 2018-12-10 16:55 UTC (permalink / raw)
To: Will Deacon
Cc: ard.biesheuvel@linaro.org, Catalin Marinas, Suzuki Poulose,
linux-mm@kvack.org, jcm@redhat.com, nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210161826.GA11135@edgewater-inn.cambridge.arm.com>
On Mon, Dec 10, 2018 at 04:18:26PM +0000, Will Deacon wrote:
> On Mon, Dec 10, 2018 at 04:04:02PM +0000, Steve Capper wrote:
> > On Mon, Dec 10, 2018 at 01:36:40PM +0000, Will Deacon wrote:
> > > On Fri, Dec 07, 2018 at 05:28:58PM +0000, Suzuki K Poulose wrote:
> > > > On 07/12/2018 15:26, Will Deacon wrote:
> > > > > On Fri, Dec 07, 2018 at 10:47:57AM +0000, Suzuki K Poulose wrote:
> > > > > > On 12/06/2018 10:50 PM, Steve Capper wrote:
> > > > > > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > > > > > > index f60081be9a1b..58fcc1edd852 100644
> > > > > > > --- a/arch/arm64/kernel/head.S
> > > > > > > +++ b/arch/arm64/kernel/head.S
> > > > > > > @@ -707,6 +707,7 @@ secondary_startup:
> > > > > > > /*
> > > > > > > * Common entry point for secondary CPUs.
> > > > > > > */
> > > > > > > + bl __cpu_secondary_check52bitva
> > > > > > > bl __cpu_setup // initialise processor
> > > > > > > adrp x1, swapper_pg_dir
> > > > > > > bl __enable_mmu
> > > > > > > @@ -785,6 +786,31 @@ ENTRY(__enable_mmu)
> > > > > > > ret
> > > > > > > ENDPROC(__enable_mmu)
> > > > > > > +ENTRY(__cpu_secondary_check52bitva)
> > > > > > > +#ifdef CONFIG_ARM64_52BIT_VA
> > > > > > > + ldr_l x0, vabits_user
> > > > > > > + cmp x0, #52
> > > > > > > + b.ne 2f > +
> > > > > > > + mrs_s x0, SYS_ID_AA64MMFR2_EL1
> > > > > > > + and x0, x0, #(0xf << ID_AA64MMFR2_LVA_SHIFT)
> > > > > > > + cbnz x0, 2f
> > > > > > > +
> > > > > > > + adr_l x0, va52mismatch
> > > > > > > + mov w1, #1
> > > > > > > + strb w1, [x0]
> > > > > > > + dmb sy
> > > > > > > + dc ivac, x0 // Invalidate potentially stale cache line
> > > > > >
> > > > > > You may have to clear this variable before a CPU is brought up to avoid
> > > > > > raising a false error message when another secondary CPU doesn't boot
> > > > > > for some other reason (say granule support) after a CPU failed with lack
> > > > > > of 52bitva. It is really a crazy corner case.
> > > > >
> > > > > Can't we just follow the example set by the EL2 setup in the way that is
> > > > > uses __boot_cpu_mode? In that case, we only need one variable and you can
> > > > > detect a problem by comparing the two halves.
> > > >
> > > > The only difference here is, the support is bolted at boot CPU time and hence
> > > > we need to verify each and every CPU, unlike the __boot_cpu_mode where we
> > > > check for mismatch after the SMP CPUs are brought up. If we decide to make
> > > > the choice later, something like that could work. The only caveat is the 52bit
> > > > kernel VA will have to do something like the above.
> > >
> > > So looking at this a bit more, I think we're better off repurposing the
> > > upper bits of the early boot status word to contain a reason code, rather
> > > than introducing new variables for every possible mismatch.
> > >
> > > Does the untested diff below look remotely sane to you?
> > >
> > > Will
> > >
> >
> > Thanks Will,
> > This looks good to me, I will test now and fold this into a patch.
>
> Cheers, Steve. Testing would be handy, but don't worry about respinning the
> patches as I'm already on top of this and hope to push this out later today.
>
Thanks Will,
This looks good to me so FWIW:
Tested-by: Steve Capper <steve.capper@arm.com>
(for both the 52-bit VA mismatch and 64KB granule not supported cases
using the model).
The only small issue I see is that if subsequent CPUs aren't brought
online (because they don't exist in the model) then the error reason is
repeated.
I'll dig into this.
Cheers,
--
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support
From: Rafael David Tinoco @ 2018-12-10 16:53 UTC (permalink / raw)
To: Russell King - ARM Linux, Robin Murphy
Cc: Rich Felker, linux-ia64, Sergey Senozhatsky, linux-sh,
James Hogan, Heiko Carstens, linux-kernel, linux-mm, Khalid Aziz,
Paul Mackerras, H . Peter Anvin, sparclinux, Catalin Marinas,
linux-s390, Yoshinori Sato, Michael Ellerman, x86, Will Deacon,
Ingo Molnar, Benjamin Herrenschmidt, Anthony Yznaga, Nitin Gupta,
Fenghua Yu, Joerg Roedel, Rafael David Tinoco, Vasily Gorbik,
Ram Pai, Nicholas Piggin, Borislav Petkov, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Juergen Gross, Tony Luck,
Jiri Kosina, linux-mips, Ralf Baechle, Minchan Kim, Paul Burton,
Christophe Leroy, Aneesh Kumar K . V, Martin Schwidefsky,
linuxppc-dev, David S . Miller, Kirill A . Shutemov
In-Reply-To: <20181210150551.GE30658@n2100.armlinux.org.uk>
On 12/10/18 1:05 PM, Russell King - ARM Linux wrote:
> On Mon, Dec 10, 2018 at 02:35:55PM +0000, Robin Murphy wrote:
>> On 10/12/2018 14:21, Rafael David Tinoco wrote:
>>> On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
>>> physical frame number might be so big that zsmalloc obj encoding (to
>>> location) will break, causing:
>>>
>>> BUG: KASAN: null-ptr-deref in zs_map_object+0xa4/0x2bc
>>> Read of size 4 at addr 00000000 by task mkfs.ext4/623
>>> CPU: 2 PID: 623 Comm: mkfs.ext4 Not tainted 4.19.0-rc8-00017-g8239bc6d3307-dirty #15
>>> Hardware name: Generic DT based system
>>> [<c0418f7c>] (unwind_backtrace) from [<c0410ca4>] (show_stack+0x20/0x24)
>>> [<c0410ca4>] (show_stack) from [<c16bd540>] (dump_stack+0xbc/0xe8)
>>> [<c16bd540>] (dump_stack) from [<c06cab74>] (kasan_report+0x248/0x390)
>>> [<c06cab74>] (kasan_report) from [<c06c94e8>] (__asan_load4+0x78/0xb4)
>>> [<c06c94e8>] (__asan_load4) from [<c06ddc24>] (zs_map_object+0xa4/0x2bc)
>>> [<c06ddc24>] (zs_map_object) from [<bf0bbbd8>] (zram_bvec_rw.constprop.2+0x324/0x8e4 [zram])
>>> [<bf0bbbd8>] (zram_bvec_rw.constprop.2 [zram]) from [<bf0bc3cc>] (zram_make_request+0x234/0x46c [zram])
>>> [<bf0bc3cc>] (zram_make_request [zram]) from [<c09aff9c>] (generic_make_request+0x304/0x63c)
>>> [<c09aff9c>] (generic_make_request) from [<c09b0320>] (submit_bio+0x4c/0x1c8)
>>> [<c09b0320>] (submit_bio) from [<c0743570>] (submit_bh_wbc.constprop.15+0x238/0x26c)
>>> [<c0743570>] (submit_bh_wbc.constprop.15) from [<c0746cf8>] (__block_write_full_page+0x524/0x76c)
>>> [<c0746cf8>] (__block_write_full_page) from [<c07472c4>] (block_write_full_page+0x1bc/0x1d4)
>>> [<c07472c4>] (block_write_full_page) from [<c0748eb4>] (blkdev_writepage+0x24/0x28)
>>> [<c0748eb4>] (blkdev_writepage) from [<c064a780>] (__writepage+0x44/0x78)
>>> [<c064a780>] (__writepage) from [<c064b50c>] (write_cache_pages+0x3b8/0x800)
>>> [<c064b50c>] (write_cache_pages) from [<c064dd78>] (generic_writepages+0x74/0xa0)
>>> [<c064dd78>] (generic_writepages) from [<c0748e64>] (blkdev_writepages+0x18/0x1c)
>>> [<c0748e64>] (blkdev_writepages) from [<c064e890>] (do_writepages+0x68/0x134)
>>> [<c064e890>] (do_writepages) from [<c06368a4>] (__filemap_fdatawrite_range+0xb0/0xf4)
>>> [<c06368a4>] (__filemap_fdatawrite_range) from [<c0636b68>] (file_write_and_wait_range+0x64/0xd0)
>>> [<c0636b68>] (file_write_and_wait_range) from [<c0747af8>] (blkdev_fsync+0x54/0x84)
>>> [<c0747af8>] (blkdev_fsync) from [<c0739dac>] (vfs_fsync_range+0x70/0xd4)
>>> [<c0739dac>] (vfs_fsync_range) from [<c0739e98>] (do_fsync+0x4c/0x80)
>>> [<c0739e98>] (do_fsync) from [<c073a26c>] (sys_fsync+0x1c/0x20)
>>> [<c073a26c>] (sys_fsync) from [<c0401000>] (ret_fast_syscall+0x0/0x2c)
>>>
>>> when trying to decode (the pfn) and map the object.
>>>
>>> That happens because one architecture might not re-define
>>> MAX_PHYSMEM_BITS, like in this ARM 32-bit w/ LPAE enabled example. For
>>> 32-bit systems, if not re-defined, MAX_POSSIBLE_PHYSMEM_BITS will
>>> default to BITS_PER_LONG (32) in most cases, and, with PAE enabled,
>>> _PFN_BITS might be wrong: which may cause obj variable to overflow if
>>> frame number is in HIGHMEM and referencing a page above the 4GB
>>> watermark.
>>>
>>> commit 6e00ec00b1a7 ("staging: zsmalloc: calculate MAX_PHYSMEM_BITS if
>>> not defined") realized MAX_PHYSMEM_BITS depended on SPARSEMEM headers
>>> and "fixed" it by calculating it using BITS_PER_LONG if SPARSEMEM wasn't
>>> used, like in the example given above.
>>>
>>> Systems with potential for PAE exist for a long time and assuming
>>> BITS_PER_LONG seems inadequate. Defining MAX_PHYSMEM_BITS looks better,
>>> however it is NOT a constant anymore for x86.
>>>
>>> SO, instead, MAX_POSSIBLE_PHYSMEM_BITS should be defined by every
>>> architecture using zsmalloc, together with a sanity check for
>>> MAX_POSSIBLE_PHYSMEM_BITS being too big on 32-bit systems.
>>>
>>> Link: https://bugs.linaro.org/show_bug.cgi?id=3765#c17
>>> Signed-off-by: Rafael David Tinoco <rafael.tinoco@linaro.org>
>>> ---
>>> arch/arm/include/asm/pgtable-2level-types.h | 2 ++
>>> arch/arm/include/asm/pgtable-3level-types.h | 2 ++
>>> arch/arm64/include/asm/pgtable-types.h | 2 ++
>>> arch/ia64/include/asm/page.h | 2 ++
>>> arch/mips/include/asm/page.h | 2 ++
>>> arch/powerpc/include/asm/mmu.h | 2 ++
>>> arch/s390/include/asm/page.h | 2 ++
>>> arch/sh/include/asm/page.h | 2 ++
>>> arch/sparc/include/asm/page_32.h | 2 ++
>>> arch/sparc/include/asm/page_64.h | 2 ++
>>> arch/x86/include/asm/pgtable-2level_types.h | 2 ++
>>> arch/x86/include/asm/pgtable-3level_types.h | 3 +-
>>> arch/x86/include/asm/pgtable_64_types.h | 4 +--
>>> mm/zsmalloc.c | 35 +++++++++++----------
>>> 14 files changed, 45 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/pgtable-2level-types.h b/arch/arm/include/asm/pgtable-2level-types.h
>>> index 66cb5b0e89c5..552dba411324 100644
>>> --- a/arch/arm/include/asm/pgtable-2level-types.h
>>> +++ b/arch/arm/include/asm/pgtable-2level-types.h
>>> @@ -64,4 +64,6 @@ typedef pteval_t pgprot_t;
>>> #endif /* STRICT_MM_TYPECHECKS */
>>> +#define MAX_POSSIBLE_PHYSMEM_BITS 32
>>> +
>>> #endif /* _ASM_PGTABLE_2LEVEL_TYPES_H */
>>> diff --git a/arch/arm/include/asm/pgtable-3level-types.h b/arch/arm/include/asm/pgtable-3level-types.h
>>> index 921aa30259c4..664c39e6517c 100644
>>> --- a/arch/arm/include/asm/pgtable-3level-types.h
>>> +++ b/arch/arm/include/asm/pgtable-3level-types.h
>>> @@ -67,4 +67,6 @@ typedef pteval_t pgprot_t;
>>> #endif /* STRICT_MM_TYPECHECKS */
>>> +#define MAX_POSSIBLE_PHYSMEM_BITS 36
>>
>> Nit: with LPAE, physical addresses go up to 40 bits, not just 36.
Hum, I got it from where it was being defined when having SPARSEMEM
enabled (#define MAX_PHYSMEM_BITS 36 in
arch/arm/include/asm/sparsemem.h), since without SPARSEMEM it would
default to BITS_PER_LONG.
> Right, with that set at 40, we get:
>
> #define _PFN_BITS (MAX_POSSIBLE_PHYSMEM_BITS - PAGE_SHIFT)
>
> == 28
>
> #define OBJ_TAG_BITS 1
> #define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS - OBJ_TAG_BITS)
>
> == 3
>
> #define ZS_MAX_ZSPAGE_ORDER 2
> #define ZS_MAX_PAGES_PER_ZSPAGE (_AC(1, UL) << ZS_MAX_ZSPAGE_ORDER)
>
> == 4
>
> #define ZS_MIN_ALLOC_SIZE \
> MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
>
> == 4 << 12 >> 3 = 2048
>
> or half-page allocations.
>
> Given this in Documentation/vm/zsmalloc.rst:
>
> On the other hand, if we just use single
> (0-order) pages, it would suffer from very high fragmentation --
> any object of size PAGE_SIZE/2 or larger would occupy an entire page.
> This was one of the major issues with its predecessor (xvmalloc).
>
> It seems that would not be acceptable, so I have to ask whether
> using an unsigned long to store PFN + object ID is really acceptable.
> Maybe the real solution to this problem is to stop using an
> unsigned long to contain both the PFN and object ID?
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/5] soc: fsl: dpio: store a backpointer to the device backing the dpaa2_io
From: Ioana Ciornei @ 2018-12-10 16:50 UTC (permalink / raw)
To: Leo Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org
Cc: Roy Pledge, Ioana Ciornei, Ioana Ciocoi Radulescu, Horia Geanta,
Laurentiu Tudor
In-Reply-To: <1544460591-14888-1-git-send-email-ioana.ciornei@nxp.com>
Add a new field in the dpaa2_io structure to hold a backpointer to the
actual DPIO device.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
drivers/soc/fsl/dpio/dpio-driver.c | 2 +-
drivers/soc/fsl/dpio/dpio-service.c | 7 ++++++-
include/soc/fsl/dpaa2-io.h | 3 ++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c
index 5286723..2d4af32 100644
--- a/drivers/soc/fsl/dpio/dpio-driver.c
+++ b/drivers/soc/fsl/dpio/dpio-driver.c
@@ -176,7 +176,7 @@ static int dpaa2_dpio_probe(struct fsl_mc_device *dpio_dev)
if (err)
goto err_register_dpio_irq;
- priv->io = dpaa2_io_create(&desc);
+ priv->io = dpaa2_io_create(&desc, dev);
if (!priv->io) {
dev_err(dev, "dpaa2_io_create failed\n");
err = -ENOMEM;
diff --git a/drivers/soc/fsl/dpio/dpio-service.c b/drivers/soc/fsl/dpio/dpio-service.c
index 5583d28..87e01710 100644
--- a/drivers/soc/fsl/dpio/dpio-service.c
+++ b/drivers/soc/fsl/dpio/dpio-service.c
@@ -27,6 +27,7 @@ struct dpaa2_io {
/* protect notifications list */
spinlock_t lock_notifications;
struct list_head notifications;
+ struct device *dev;
};
struct dpaa2_io_store {
@@ -98,13 +99,15 @@ struct dpaa2_io *dpaa2_io_service_select(int cpu)
/**
* dpaa2_io_create() - create a dpaa2_io object.
* @desc: the dpaa2_io descriptor
+ * @dev: the actual DPIO device
*
* Activates a "struct dpaa2_io" corresponding to the given config of an actual
* DPIO object.
*
* Return a valid dpaa2_io object for success, or NULL for failure.
*/
-struct dpaa2_io *dpaa2_io_create(const struct dpaa2_io_desc *desc)
+struct dpaa2_io *dpaa2_io_create(const struct dpaa2_io_desc *desc,
+ struct device *dev)
{
struct dpaa2_io *obj = kmalloc(sizeof(*obj), GFP_KERNEL);
@@ -146,6 +149,8 @@ struct dpaa2_io *dpaa2_io_create(const struct dpaa2_io_desc *desc)
dpio_by_cpu[desc->cpu] = obj;
spin_unlock(&dpio_list_lock);
+ obj->dev = dev;
+
return obj;
}
diff --git a/include/soc/fsl/dpaa2-io.h b/include/soc/fsl/dpaa2-io.h
index e11eed1..5b5ba26 100644
--- a/include/soc/fsl/dpaa2-io.h
+++ b/include/soc/fsl/dpaa2-io.h
@@ -57,7 +57,8 @@ struct dpaa2_io_desc {
u32 qman_version;
};
-struct dpaa2_io *dpaa2_io_create(const struct dpaa2_io_desc *desc);
+struct dpaa2_io *dpaa2_io_create(const struct dpaa2_io_desc *desc,
+ struct device *dev);
void dpaa2_io_down(struct dpaa2_io *d);
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/5] soc: fsl: dpio: keep a per dpio device MC portal
From: Ioana Ciornei @ 2018-12-10 16:50 UTC (permalink / raw)
To: Leo Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org
Cc: Roy Pledge, Ioana Ciornei, Ioana Ciocoi Radulescu, Horia Geanta,
Laurentiu Tudor
In-Reply-To: <1544460591-14888-1-git-send-email-ioana.ciornei@nxp.com>
At the moment, the dpio-driver allocates an MC portal at probe time and
frees it right after usage. The same thing happens on the remove path.
This behavior could lead to scenarios where an MC portal is available
for use at probing but not longer free on the remove path which could
lead to unproper unbind of resources.
Change the driver's behavior in such a way that an MC portal is
allocated at probe and kept until the DPIO device is removed. This will
ensure that at any time after a DPIO device was successfully probed, all
its dependencies will be met.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
drivers/soc/fsl/dpio/dpio-driver.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c
index 38ee9db..5286723 100644
--- a/drivers/soc/fsl/dpio/dpio-driver.c
+++ b/drivers/soc/fsl/dpio/dpio-driver.c
@@ -187,7 +187,6 @@ static int dpaa2_dpio_probe(struct fsl_mc_device *dpio_dev)
dev_dbg(dev, " receives_notifications = %d\n",
desc.receives_notifications);
dpio_close(dpio_dev->mc_io, 0, dpio_dev->mc_handle);
- fsl_mc_portal_free(dpio_dev->mc_io);
return 0;
@@ -229,12 +228,6 @@ static int dpaa2_dpio_remove(struct fsl_mc_device *dpio_dev)
cpu = dpaa2_io_get_cpu(priv->io);
cpumask_set_cpu(cpu, cpus_unused_mask);
- err = fsl_mc_portal_allocate(dpio_dev, 0, &dpio_dev->mc_io);
- if (err) {
- dev_err(dev, "MC portal allocation failed\n");
- goto err_mcportal;
- }
-
err = dpio_open(dpio_dev->mc_io, 0, dpio_dev->obj_desc.id,
&dpio_dev->mc_handle);
if (err) {
@@ -252,7 +245,7 @@ static int dpaa2_dpio_remove(struct fsl_mc_device *dpio_dev)
err_open:
fsl_mc_portal_free(dpio_dev->mc_io);
-err_mcportal:
+
return err;
}
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/5] bus: fsl-mc: automatically add a device_link on fsl_mc_[portal,object]_allocate
From: Ioana Ciornei @ 2018-12-10 16:50 UTC (permalink / raw)
To: Leo Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org
Cc: Roy Pledge, Ioana Ciornei, Ioana Ciocoi Radulescu, Horia Geanta,
Laurentiu Tudor
In-Reply-To: <1544460591-14888-1-git-send-email-ioana.ciornei@nxp.com>
Allocatable devices can be acquired by drivers on the fsl-mc bus using
the fsl_mc_portal_allocate or fsl_mc_object_allocate functions. Add a
device link between the consumer device and the supplier device so that
proper resource management is achieved.
Also, adding a link between these devices ensures that a proper unbind
order is respected (ie before the supplier device is unbound from its
respective driver all consumer devices will be notified and unbound
first).
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
drivers/bus/fsl-mc/fsl-mc-allocator.c | 11 +++++++++++
drivers/bus/fsl-mc/mc-io.c | 13 +++++++++++++
include/linux/fsl/mc.h | 1 +
3 files changed, 25 insertions(+)
diff --git a/drivers/bus/fsl-mc/fsl-mc-allocator.c b/drivers/bus/fsl-mc/fsl-mc-allocator.c
index e906ecfe..8ad7724 100644
--- a/drivers/bus/fsl-mc/fsl-mc-allocator.c
+++ b/drivers/bus/fsl-mc/fsl-mc-allocator.c
@@ -295,6 +295,14 @@ int __must_check fsl_mc_object_allocate(struct fsl_mc_device *mc_dev,
if (!mc_adev)
goto error;
+ mc_adev->consumer_link = device_link_add(&mc_dev->dev,
+ &mc_adev->dev,
+ DL_FLAG_AUTOREMOVE_CONSUMER);
+ if (!mc_adev->consumer_link) {
+ error = -EINVAL;
+ goto error;
+ }
+
*new_mc_adev = mc_adev;
return 0;
error:
@@ -321,6 +329,9 @@ void fsl_mc_object_free(struct fsl_mc_device *mc_adev)
return;
fsl_mc_resource_free(resource);
+
+ device_link_del(mc_adev->consumer_link);
+ mc_adev->consumer_link = NULL;
}
EXPORT_SYMBOL_GPL(fsl_mc_object_free);
diff --git a/drivers/bus/fsl-mc/mc-io.c b/drivers/bus/fsl-mc/mc-io.c
index 7226cfc..3ae574a 100644
--- a/drivers/bus/fsl-mc/mc-io.c
+++ b/drivers/bus/fsl-mc/mc-io.c
@@ -209,9 +209,19 @@ int __must_check fsl_mc_portal_allocate(struct fsl_mc_device *mc_dev,
if (error < 0)
goto error_cleanup_resource;
+ dpmcp_dev->consumer_link = device_link_add(&mc_dev->dev,
+ &dpmcp_dev->dev,
+ DL_FLAG_AUTOREMOVE_CONSUMER);
+ if (!dpmcp_dev->consumer_link) {
+ error = -EINVAL;
+ goto error_cleanup_mc_io;
+ }
+
*new_mc_io = mc_io;
return 0;
+error_cleanup_mc_io:
+ fsl_destroy_mc_io(mc_io);
error_cleanup_resource:
fsl_mc_resource_free(resource);
return error;
@@ -244,6 +254,9 @@ void fsl_mc_portal_free(struct fsl_mc_io *mc_io)
fsl_destroy_mc_io(mc_io);
fsl_mc_resource_free(resource);
+
+ device_link_del(dpmcp_dev->consumer_link);
+ dpmcp_dev->consumer_link = NULL;
}
EXPORT_SYMBOL_GPL(fsl_mc_portal_free);
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index 9d3f668..0c4f9805 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -193,6 +193,7 @@ struct fsl_mc_device {
struct resource *regions;
struct fsl_mc_device_irq **irqs;
struct fsl_mc_resource *resource;
+ struct device_link *consumer_link;
};
#define to_fsl_mc_device(_dev) \
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/5] soc: fsl: dpio: add a device_link at dpaa2_io_service_register
From: Ioana Ciornei @ 2018-12-10 16:50 UTC (permalink / raw)
To: Leo Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org
Cc: Roy Pledge, Ioana Ciornei, Ioana Ciocoi Radulescu, Horia Geanta,
Laurentiu Tudor
In-Reply-To: <1544460591-14888-1-git-send-email-ioana.ciornei@nxp.com>
Automatically add a device link between the actual device requesting the
dpaa2_io_service_register and the underlying dpaa2_io used. This link
will ensure that when a DPIO device, which is indirectly used by other
devices, is unbound any consumer devices will be also unbound from their
drivers.
For example, any DPNI, bound to the dpaa2-eth driver, which is using
DPIO devices will be unbound before its supplier device.
Also, add a new parameter to the dpaa2_io_service_[de]register functions
to specify the requesting device (ie the consumer).
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
drivers/crypto/caam/caamalg_qi2.c | 6 +++---
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 9 +++++----
drivers/soc/fsl/dpio/dpio-service.c | 16 ++++++++++++++--
include/soc/fsl/dpaa2-io.h | 6 ++++--
4 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/caam/caamalg_qi2.c b/drivers/crypto/caam/caamalg_qi2.c
index 7d8ac02..3167539 100644
--- a/drivers/crypto/caam/caamalg_qi2.c
+++ b/drivers/crypto/caam/caamalg_qi2.c
@@ -4371,7 +4371,7 @@ static int __cold dpaa2_dpseci_dpio_setup(struct dpaa2_caam_priv *priv)
nctx->cb = dpaa2_caam_fqdan_cb;
/* Register notification callbacks */
- err = dpaa2_io_service_register(NULL, nctx);
+ err = dpaa2_io_service_register(NULL, nctx, dev);
if (unlikely(err)) {
dev_dbg(dev, "No affine DPIO for cpu %d\n", cpu);
nctx->cb = NULL;
@@ -4404,7 +4404,7 @@ static int __cold dpaa2_dpseci_dpio_setup(struct dpaa2_caam_priv *priv)
ppriv = per_cpu_ptr(priv->ppriv, cpu);
if (!ppriv->nctx.cb)
break;
- dpaa2_io_service_deregister(NULL, &ppriv->nctx);
+ dpaa2_io_service_deregister(NULL, &ppriv->nctx, dev);
}
for_each_online_cpu(cpu) {
@@ -4424,7 +4424,7 @@ static void __cold dpaa2_dpseci_dpio_free(struct dpaa2_caam_priv *priv)
for_each_online_cpu(cpu) {
ppriv = per_cpu_ptr(priv->ppriv, cpu);
- dpaa2_io_service_deregister(NULL, &ppriv->nctx);
+ dpaa2_io_service_deregister(NULL, &ppriv->nctx, priv->dev);
dpaa2_io_store_destroy(ppriv->store);
if (++i == priv->num_pairs)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
index 04d5c44..e8790f9 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
@@ -1570,7 +1570,7 @@ static int setup_dpio(struct dpaa2_eth_priv *priv)
/* Register the new context */
channel->dpio = dpaa2_io_service_select(i);
- err = dpaa2_io_service_register(channel->dpio, nctx);
+ err = dpaa2_io_service_register(channel->dpio, nctx, dev);
if (err) {
dev_dbg(dev, "No affine DPIO for cpu %d\n", i);
/* If no affine DPIO for this core, there's probably
@@ -1610,7 +1610,7 @@ static int setup_dpio(struct dpaa2_eth_priv *priv)
return 0;
err_set_cdan:
- dpaa2_io_service_deregister(channel->dpio, nctx);
+ dpaa2_io_service_deregister(channel->dpio, nctx, dev);
err_service_reg:
free_channel(priv, channel);
err_alloc_ch:
@@ -1630,13 +1630,14 @@ static int setup_dpio(struct dpaa2_eth_priv *priv)
static void free_dpio(struct dpaa2_eth_priv *priv)
{
- int i;
+ struct device *dev = priv->net_dev->dev.parent;
struct dpaa2_eth_channel *ch;
+ int i;
/* deregister CDAN notifications and free channels */
for (i = 0; i < priv->num_channels; i++) {
ch = priv->channel[i];
- dpaa2_io_service_deregister(ch->dpio, &ch->nctx);
+ dpaa2_io_service_deregister(ch->dpio, &ch->nctx, dev);
free_channel(priv, ch);
}
}
diff --git a/drivers/soc/fsl/dpio/dpio-service.c b/drivers/soc/fsl/dpio/dpio-service.c
index 87e01710..01b24ac 100644
--- a/drivers/soc/fsl/dpio/dpio-service.c
+++ b/drivers/soc/fsl/dpio/dpio-service.c
@@ -237,6 +237,7 @@ int dpaa2_io_get_cpu(struct dpaa2_io *d)
* notifications on the given DPIO service.
* @d: the given DPIO service.
* @ctx: the notification context.
+ * @dev: the device that requests the register
*
* The caller should make the MC command to attach a DPAA2 object to
* a DPIO after this function completes successfully. In that way:
@@ -251,14 +252,20 @@ int dpaa2_io_get_cpu(struct dpaa2_io *d)
* Return 0 for success, or -ENODEV for failure.
*/
int dpaa2_io_service_register(struct dpaa2_io *d,
- struct dpaa2_io_notification_ctx *ctx)
+ struct dpaa2_io_notification_ctx *ctx,
+ struct device *dev)
{
+ struct device_link *link;
unsigned long irqflags;
d = service_select_by_cpu(d, ctx->desired_cpu);
if (!d)
return -ENODEV;
+ link = device_link_add(dev, d->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
+ if (!link)
+ return -EINVAL;
+
ctx->dpio_id = d->dpio_desc.dpio_id;
ctx->qman64 = (u64)(uintptr_t)ctx;
ctx->dpio_private = d;
@@ -279,12 +286,14 @@ int dpaa2_io_service_register(struct dpaa2_io *d,
* dpaa2_io_service_deregister - The opposite of 'register'.
* @service: the given DPIO service.
* @ctx: the notification context.
+ * @dev: the device that requests to be deregistered
*
* This function should be called only after sending the MC command to
* to detach the notification-producing device from the DPIO.
*/
void dpaa2_io_service_deregister(struct dpaa2_io *service,
- struct dpaa2_io_notification_ctx *ctx)
+ struct dpaa2_io_notification_ctx *ctx,
+ struct device *dev)
{
struct dpaa2_io *d = ctx->dpio_private;
unsigned long irqflags;
@@ -295,6 +304,9 @@ void dpaa2_io_service_deregister(struct dpaa2_io *service,
spin_lock_irqsave(&d->lock_notifications, irqflags);
list_del(&ctx->node);
spin_unlock_irqrestore(&d->lock_notifications, irqflags);
+
+ if (dev)
+ device_link_remove(dev, d->dev);
}
EXPORT_SYMBOL_GPL(dpaa2_io_service_deregister);
diff --git a/include/soc/fsl/dpaa2-io.h b/include/soc/fsl/dpaa2-io.h
index 5b5ba26..850e46d 100644
--- a/include/soc/fsl/dpaa2-io.h
+++ b/include/soc/fsl/dpaa2-io.h
@@ -94,9 +94,11 @@ struct dpaa2_io_notification_ctx {
int dpaa2_io_get_cpu(struct dpaa2_io *d);
int dpaa2_io_service_register(struct dpaa2_io *service,
- struct dpaa2_io_notification_ctx *ctx);
+ struct dpaa2_io_notification_ctx *ctx,
+ struct device *dev);
void dpaa2_io_service_deregister(struct dpaa2_io *service,
- struct dpaa2_io_notification_ctx *ctx);
+ struct dpaa2_io_notification_ctx *ctx,
+ struct device *dev);
int dpaa2_io_service_rearm(struct dpaa2_io *service,
struct dpaa2_io_notification_ctx *ctx);
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/5] soc: fsl: dpio: perform DPIO Reset on Probe
From: Ioana Ciornei @ 2018-12-10 16:50 UTC (permalink / raw)
To: Leo Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org
Cc: Roy Pledge, Ioana Ciocoi Radulescu, Horia Geanta, Laurentiu Tudor
In-Reply-To: <1544460591-14888-1-git-send-email-ioana.ciornei@nxp.com>
From: Roy Pledge <roy.pledge@nxp.com>
Invoke a DPIO reset command when a DPIO device is probed. This
will ensure the QBMan portal is in the state the driver expects.
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
drivers/soc/fsl/dpio/dpio-cmd.h | 1 +
drivers/soc/fsl/dpio/dpio-driver.c | 7 +++++++
drivers/soc/fsl/dpio/dpio.c | 23 +++++++++++++++++++++++
drivers/soc/fsl/dpio/dpio.h | 4 ++++
4 files changed, 35 insertions(+)
diff --git a/drivers/soc/fsl/dpio/dpio-cmd.h b/drivers/soc/fsl/dpio/dpio-cmd.h
index ab8f82e..5814d2f 100644
--- a/drivers/soc/fsl/dpio/dpio-cmd.h
+++ b/drivers/soc/fsl/dpio/dpio-cmd.h
@@ -25,6 +25,7 @@
#define DPIO_CMDID_ENABLE DPIO_CMD(0x002)
#define DPIO_CMDID_DISABLE DPIO_CMD(0x003)
#define DPIO_CMDID_GET_ATTR DPIO_CMD(0x004)
+#define DPIO_CMDID_RESET DPIO_CMD(0x005)
struct dpio_cmd_open {
__le32 dpio_id;
diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c
index 832175c..38ee9db 100644
--- a/drivers/soc/fsl/dpio/dpio-driver.c
+++ b/drivers/soc/fsl/dpio/dpio-driver.c
@@ -110,6 +110,12 @@ static int dpaa2_dpio_probe(struct fsl_mc_device *dpio_dev)
goto err_open;
}
+ err = dpio_reset(dpio_dev->mc_io, 0, dpio_dev->mc_handle);
+ if (err) {
+ dev_err(dev, "dpio_reset() failed\n");
+ goto err_reset;
+ }
+
err = dpio_get_attributes(dpio_dev->mc_io, 0, dpio_dev->mc_handle,
&dpio_attrs);
if (err) {
@@ -192,6 +198,7 @@ static int dpaa2_dpio_probe(struct fsl_mc_device *dpio_dev)
err_allocate_irqs:
dpio_disable(dpio_dev->mc_io, 0, dpio_dev->mc_handle);
err_get_attr:
+err_reset:
dpio_close(dpio_dev->mc_io, 0, dpio_dev->mc_handle);
err_open:
fsl_mc_portal_free(dpio_dev->mc_io);
diff --git a/drivers/soc/fsl/dpio/dpio.c b/drivers/soc/fsl/dpio/dpio.c
index ff37c80..521bc69 100644
--- a/drivers/soc/fsl/dpio/dpio.c
+++ b/drivers/soc/fsl/dpio/dpio.c
@@ -196,3 +196,26 @@ int dpio_get_api_version(struct fsl_mc_io *mc_io,
return 0;
}
+
+/**
+ * dpio_reset() - Reset the DPIO, returns the object to initial state.
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPIO object
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpio_reset(struct fsl_mc_io *mc_io,
+ u32 cmd_flags,
+ u16 token)
+{
+ struct fsl_mc_command cmd = { 0 };
+
+ /* prepare command */
+ cmd.header = mc_encode_cmd_header(DPIO_CMDID_RESET,
+ cmd_flags,
+ token);
+
+ /* send command to mc*/
+ return mc_send_command(mc_io, &cmd);
+}
diff --git a/drivers/soc/fsl/dpio/dpio.h b/drivers/soc/fsl/dpio/dpio.h
index 49194c8..b2ac4ba 100644
--- a/drivers/soc/fsl/dpio/dpio.h
+++ b/drivers/soc/fsl/dpio/dpio.h
@@ -80,4 +80,8 @@ int dpio_get_api_version(struct fsl_mc_io *mc_io,
u16 *major_ver,
u16 *minor_ver);
+int dpio_reset(struct fsl_mc_io *mc_io,
+ u32 cmd_flags,
+ u16 token);
+
#endif /* __FSL_DPIO_H */
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/5] soc: fsl: add device links support for devices on the fsl-mc bus
From: Ioana Ciornei @ 2018-12-10 16:50 UTC (permalink / raw)
To: Leo Li, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org
Cc: Roy Pledge, Ioana Ciornei, Ioana Ciocoi Radulescu, Horia Geanta,
Laurentiu Tudor
The fsl-mc bus discovers and exports devices dynamically allocated
by the Management Complex firmware.
This patch set adds the ability to automatically create a device link
between a consumer device on the fsl-mc bus and a supplier one.
For example, a dpni device (a network interface) requests access to a
dpio device (I/O portal) using the dpaa2_io_service_register function
which is enhanced to also add the corresponding device link between
them.
The first 3 patches set the stage for a proper handling of device
links while the following 2 are the ones that add the actual links.
The internal management of the links is not exported to the consumer
driver, but it's rather included in the functions that actually allocate
the provider device: fsl_mc_portal_allocate, fsl_mc_object_allocate and
dpaa2_io_service_register.
Ioana Ciornei (4):
soc: fsl: dpio: keep a per dpio device MC portal
soc: fsl: dpio: store a backpointer to the device backing the dpaa2_io
soc: fsl: dpio: add a device_link at dpaa2_io_service_register
bus: fsl-mc: automatically add a device_link on
fsl_mc_[portal,object]_allocate
Roy Pledge (1):
soc: fsl: dpio: perform DPIO Reset on Probe
drivers/bus/fsl-mc/fsl-mc-allocator.c | 11 +++++++++++
drivers/bus/fsl-mc/mc-io.c | 13 +++++++++++++
drivers/crypto/caam/caamalg_qi2.c | 6 +++---
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 9 +++++----
drivers/soc/fsl/dpio/dpio-cmd.h | 1 +
drivers/soc/fsl/dpio/dpio-driver.c | 18 +++++++++---------
drivers/soc/fsl/dpio/dpio-service.c | 23 ++++++++++++++++++++---
drivers/soc/fsl/dpio/dpio.c | 23 +++++++++++++++++++++++
drivers/soc/fsl/dpio/dpio.h | 4 ++++
include/linux/fsl/mc.h | 1 +
include/soc/fsl/dpaa2-io.h | 9 ++++++---
11 files changed, 96 insertions(+), 22 deletions(-)
--
1.9.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support
From: Rafael David Tinoco @ 2018-12-10 16:48 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Rich Felker, linux-ia64, Sergey Senozhatsky, linux-sh,
Catalin Marinas, Heiko Carstens, Ram Pai, linux-mips, linux-mm,
Khalid Aziz, Paul Mackerras, H . Peter Anvin, sparclinux,
linux-s390, Yoshinori Sato, Michael Ellerman, x86, Russell King,
Ingo Molnar, Benjamin Herrenschmidt, James Hogan, Anthony Yznaga,
Nitin Gupta, Fenghua Yu, Joerg Roedel, Rafael David Tinoco,
Juergen Gross, Vasily Gorbik, Will Deacon, Nicholas Piggin,
Borislav Petkov, Andy Lutomirski, Thomas Gleixner,
linux-arm-kernel, Christophe Leroy, Tony Luck, Jiri Kosina,
linux-kernel, Ralf Baechle, Minchan Kim, Paul Burton,
Aneesh Kumar K . V, Martin Schwidefsky, linuxppc-dev,
David S . Miller, Kirill A . Shutemov
In-Reply-To: <20181210151506.phyjkfcg3skogtyh@kshutemo-mobl1>
On 12/10/18 1:15 PM, Kirill A. Shutemov wrote:
> On Mon, Dec 10, 2018 at 12:21:05PM -0200, Rafael David Tinoco wrote:
>> diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
>> index 84bd9bdc1987..d808cfde3d19 100644
>> --- a/arch/x86/include/asm/pgtable_64_types.h
>> +++ b/arch/x86/include/asm/pgtable_64_types.h
>> @@ -64,8 +64,6 @@ extern unsigned int ptrs_per_p4d;
>> #define P4D_SIZE (_AC(1, UL) << P4D_SHIFT)
>> #define P4D_MASK (~(P4D_SIZE - 1))
>>
>> -#define MAX_POSSIBLE_PHYSMEM_BITS 52
>> -
>> #else /* CONFIG_X86_5LEVEL */
>>
>> /*
>> @@ -154,4 +152,6 @@ extern unsigned int ptrs_per_p4d;
>>
>> #define PGD_KERNEL_START ((PAGE_SIZE / 2) / sizeof(pgd_t))
>>
>> +#define MAX_POSSIBLE_PHYSMEM_BITS (pgtable_l5_enabled() ? 52 : 46)
>> +
>
> ...
>
>> #endif /* _ASM_X86_PGTABLE_64_DEFS_H */
>> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
>> index 0787d33b80d8..132c20b6fd4f 100644
>> --- a/mm/zsmalloc.c
>> +++ b/mm/zsmalloc.c
>
> ...
>
>> @@ -116,6 +100,25 @@
>> */
>> #define OBJ_ALLOCATED_TAG 1
>> #define OBJ_TAG_BITS 1
>> +
>> +/*
>> + * MAX_POSSIBLE_PHYSMEM_BITS should be defined by all archs using zsmalloc:
>> + * Trying to guess it from MAX_PHYSMEM_BITS, or considering it BITS_PER_LONG,
>> + * proved to be wrong by not considering PAE capabilities, or using SPARSEMEM
>> + * only headers, leading to bad object encoding due to object index overflow.
>> + */
>> +#ifndef MAX_POSSIBLE_PHYSMEM_BITS
>> + #define MAX_POSSIBLE_PHYSMEM_BITS BITS_PER_LONG
>> + #error "MAX_POSSIBLE_PHYSMEM_BITS HAS to be defined by arch using zsmalloc";
>> +#else
>> + #ifndef CONFIG_64BIT
>> + #if (MAX_POSSIBLE_PHYSMEM_BITS >= (BITS_PER_LONG + PAGE_SHIFT - OBJ_TAG_BITS))
>> + #error "MAX_POSSIBLE_PHYSMEM_BITS is wrong for this arch";
>> + #endif
>> + #endif
>> +#endif
>> +
>> +#define _PFN_BITS (MAX_POSSIBLE_PHYSMEM_BITS - PAGE_SHIFT)
>> #define OBJ_INDEX_BITS (BITS_PER_LONG - _PFN_BITS - OBJ_TAG_BITS)
>> #define OBJ_INDEX_MASK ((_AC(1, UL) << OBJ_INDEX_BITS) - 1)
>
> Have you tested it with CONFIG_X86_5LEVEL=y?
>
> ASAICS, the patch makes OBJ_INDEX_BITS and what depends from it dynamic --
> it depends what paging mode we are booting in. ZS_SIZE_CLASSES depends
> indirectly on OBJ_INDEX_BITS and I don't see how struct zs_pool definition
> can compile with dynamic ZS_SIZE_CLASSES.
>
> Hm?
>
You're right, terribly sorry. This was a last time change.
mm/zsmalloc.c:256:21: error: variably modified ‘size_class’ at file scope
I'll revisit the patch. Any other comments are welcome.
Thank you
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: TK1: DRM, Nouveau and VIC
From: Marcel Ziswiler @ 2018-12-10 16:38 UTC (permalink / raw)
To: thierry.reding@gmail.com
Cc: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
mperttunen@nvidia.com, bskeggs@redhat.com,
linux-tegra@vger.kernel.org, jonathanh@nvidia.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20181210162317.GA4789@ulmo>
Hi Thierry
On Mon, 2018-12-10 at 17:23 +0100, Thierry Reding wrote:
Snip.
> > Looks like with pci_disable_device() it may take a rather strange
> > path...
>
> Yikes... it has no business at all calling pci_disable_device() on
> Tegra. Unless if you happen to have a GPU plugged into the PCIe slot.
> I'm assuming that's not what you're doing?
Nope, I only have a Wi-Fi card behind a PCIe switch though (;-p).
> I'll see if I can reproduce (and fix) that crash on unload.
> Admittedly
> it's not something that I regularly test. Perhaps that's something
> that
> I should change...
Don't worry. After a couple of years working on this I happen to try
this the first time myself just now (;-p).
> Thierry
Cheers
Marcel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL RESEND] ARM: dts: uniphier: UniPhier DT updates for v4.21/v5.0
From: Masahiro Yamada @ 2018-12-10 16:37 UTC (permalink / raw)
To: arm-soc, Arnd Bergmann, Olof Johansson
Cc: Linux Kernel Mailing List, linux-arm-kernel
Hi Arnd, Olof,
Please pull UniPhier DT updates for the v4.21/v5.0 MW.
Thanks!
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
tags/uniphier-dt-v4.21
for you to fetch changes up to 5fd98eb7e8ce0f7d7e4f3c138e5b46fc98389804:
ARM: dts: uniphier: add MIO DMAC nodes (2018-12-11 01:31:17 +0900)
----------------------------------------------------------------
UniPhier ARM SoC DT updates for v4.21
- Add bindings for all SoCs/boards of UniPhier platform
- Move binding docs to socionext directory
- Add all CPUs in cooling maps
- Add MIO DMAC nodes
----------------------------------------------------------------
Masahiro Yamada (3):
dt-bindings: uniphier: add bindings for UniPhier SoC family
dt-bindings: uniphier: move cache-uniphier.txt to vendor directory
ARM: dts: uniphier: add MIO DMAC nodes
Viresh Kumar (2):
ARM: dts: uniphier: Add all CPUs in cooling maps
arm64: dts: uniphier: Add all CPUs in cooling maps
.../arm/{uniphier => socionext}/cache-uniphier.txt | 0
.../devicetree/bindings/arm/socionext/uniphier.txt | 47 ++++++++++++++++++++++
MAINTAINERS | 1 +
arch/arm/boot/dts/uniphier-ld4.dtsi | 14 +++++++
arch/arm/boot/dts/uniphier-pro4.dtsi | 16 ++++++++
arch/arm/boot/dts/uniphier-pxs2.dtsi | 6 ++-
arch/arm/boot/dts/uniphier-sld8.dtsi | 14 +++++++
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 11 ++---
8 files changed, 100 insertions(+), 9 deletions(-)
rename Documentation/devicetree/bindings/arm/{uniphier =>
socionext}/cache-uniphier.txt (100%)
create mode 100644 Documentation/devicetree/bindings/arm/socionext/uniphier.txt
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v4.21
From: Masahiro Yamada @ 2018-12-10 16:28 UTC (permalink / raw)
To: arm-soc, Olof Johansson, Arnd Bergmann
Cc: Linux Kernel Mailing List, linux-arm-kernel
In-Reply-To: <CAK7LNASah-5o_sAUw=DDwfKhY=rYXZ1dmeX+d_HhKNMGqKLLAQ@mail.gmail.com>
On Tue, Dec 11, 2018 at 1:24 AM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> Hi Arnd, Olof,
>
> Please pull UniPhier DT updates for the v4.20 MW.
>
> In this cycle, I queued up all arm/arm64 changes
> into a single branch to avoid build errors.
>
> Thanks!
Sorry, please discard this.
Looks like I accidentally hit the send-button
before finishing it.
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/4] ARM: mm: permit memblock resizing right after mapping the linear region
From: Ard Biesheuvel @ 2018-12-10 16:29 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Marc Zyngier, linux-efi, Russell King, Ard Biesheuvel
In-Reply-To: <20181210162949.8597-1-ard.biesheuvel@linaro.org>
The memblock arrays can be resized dynamically if needed, but this is
only done after memblock_allow_resize() is called, since it is up to
the architecture to decide at which point doing so is possible (i.e.,
when all the memory that memblock describes is actually mapped)
ARM grants this permission in bootmem_init(), but in order for the EFI
persistent memory reservation code (which may create memblock
reservations that trigger such a dynamic resize) to be able to be called
before shutting down early fixmap (upon which the EFI code depends due
to its use of early_memremap()), we need to do this earlier.
So let's move the call to memblock_allow_resize() to right after the
point where low memory is mapped and declared as the memory limit for
memblock allocation.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/mm/init.c | 1 -
arch/arm/mm/mmu.c | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 32e4845af2b6..797fad2b16ee 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -304,7 +304,6 @@ void __init bootmem_init(void)
{
unsigned long min, max_low, max_high;
- memblock_allow_resize();
max_low = max_high = 0;
find_limits(&min, &max_low, &max_high);
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f5cc1ccfea3d..f6bf6686559d 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1626,6 +1626,7 @@ void __init paging_init(const struct machine_desc *mdesc)
prepare_page_table();
map_lowmem();
memblock_set_current_limit(arm_lowmem_limit);
+ memblock_allow_resize();
dma_contiguous_remap();
early_fixmap_shutdown();
devicemaps_init(mdesc);
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/4] ARM: re-enable EFI persistent memory reservations
From: Ard Biesheuvel @ 2018-12-10 16:29 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Marc Zyngier, linux-efi, Russell King, Ard Biesheuvel
The EFI persistent memory reservations introduced during the v4.20
merge window had some teething issue, and we ended up disabling it
temporarily for 32-bit ARM due to the fact that the needed changes
were not as straightforward as on arm64.
So this series fixes the issues, and re-enables the feature for
32-bit ARM.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Ard Biesheuvel (4):
ARM: mm: permit memblock resizing right after mapping the linear
region
ARM: mm: permit early_memremap() to be used in paging_init()
efi/arm: apply persistent memory reservations during paging_init()
efi/arm: re-enable the memreserve table for 32-bit ARM
arch/arm/kernel/setup.c | 2 --
arch/arm/mm/init.c | 1 -
arch/arm/mm/mmu.c | 5 +++++
drivers/firmware/efi/libstub/arm-stub.c | 3 ---
4 files changed, 5 insertions(+), 6 deletions(-)
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] Prepare devicetrees for the new FSL QSPI driver
From: Schrempf Frieder @ 2018-12-10 16:31 UTC (permalink / raw)
To: Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Cc: boris.brezillon@bootlin.com, broonie@kernel.org,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org
In-Reply-To: <1544459182-23655-1-git-send-email-frieder.schrempf@kontron.de>
Hi FSL/ARM maintainers,
On 10.12.18 17:26, Schrempf Frieder wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> We have prepared a new driver for the FSL QSPI controller that works under
> the SPI framework. The current devicetrees are broken because they use an
> inconsistent scheme for assigning the reg properties.
>
> As, in contrast to the current driver, the new driver will use the reg
> properties to select the correct chip, we need to fix them.
>
> We also add spi-[tx/rx]-bus-width to make sure the full buswidth will be used
> and while at it clean up and remove some unused properties.
could you please consider these devicetree patches for v4.21?
We have the new FSL QSPI driver under the SPI framework ([1]) ready, but
we need some small fixes to the devicetrees that are currently broken.
As the new driver depends on these changes (mainly the change to the reg
properties) and it is not possible to add compatibility for the old
bindings, it would be really nice to have them in v4.21, so we can queue
the driver for v4.22 or whatever the next release will be called.
Please also see [2] for some more explanation.
Thanks,
Frieder
[1] https://patchwork.ozlabs.org/cover/1007641/
[2] https://patchwork.ozlabs.org/patch/922817/#1925445
>
> Frieder Schrempf (5):
> arm64: dts: Remove unused properties from FSL QSPI driver nodes
> ARM: dts: Remove unused properties from FSL QSPI driver nodes
> ARM: dts: imx6sx-sdb: Fix the reg properties for the FSL QSPI nodes
> arm64: dts: Add spi-[tx/rx]-bus-width for the FSL QSPI controller
> ARM: dts: Add spi-[tx/rx]-bus-width for the FSL QSPI controller
>
> arch/arm/boot/dts/imx6sx-sdb-reva.dts | 8 ++++++--
> arch/arm/boot/dts/imx6sx-sdb.dts | 8 ++++++--
> arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 2 ++
> arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 5 ++---
> arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 3 ++-
> arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts | 4 ++--
> arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 6 ++++--
> arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 4 ++++
> 8 files changed, 28 insertions(+), 12 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/9] arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range
From: Robin Murphy @ 2018-12-10 16:32 UTC (permalink / raw)
To: Souptick Joarder, Andrew Morton, Matthew Wilcox, Michal Hocko,
Russell King - ARM Linux, iamjoonsoo.kim, treding, Kees Cook,
Marek Szyprowski
Cc: Linux-MM, linux-kernel, linux-arm-kernel
In-Reply-To: <CAFqt6zY9JjGhedtmhYh-+mxSMrYs6P5vtQDMSzCfL02CbLys=g@mail.gmail.com>
On 08/12/2018 20:01, Souptick Joarder wrote:
> Hi Robin,
>
> On Fri, Dec 7, 2018 at 12:07 AM Souptick Joarder <jrdr.linux@gmail.com> wrote:
>>
>> Convert to use vm_insert_range() to map range of kernel
>> memory to user vma.
>>
>> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
>> ---
>> arch/arm/mm/dma-mapping.c | 21 +++++++--------------
>> 1 file changed, 7 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>> index 661fe48..4eec323 100644
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -1582,31 +1582,24 @@ static int __arm_iommu_mmap_attrs(struct device *dev, struct vm_area_struct *vma
>> void *cpu_addr, dma_addr_t dma_addr, size_t size,
>> unsigned long attrs)
>> {
>> - unsigned long uaddr = vma->vm_start;
>> - unsigned long usize = vma->vm_end - vma->vm_start;
>> + unsigned long page_count = vma_pages(vma);
>> struct page **pages = __iommu_get_pages(cpu_addr, attrs);
>> unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
>> unsigned long off = vma->vm_pgoff;
>> + int err;
>>
>> if (!pages)
>> return -ENXIO;
>>
>> - if (off >= nr_pages || (usize >> PAGE_SHIFT) > nr_pages - off)
>> + if (off >= nr_pages || page_count > nr_pages - off)
>> return -ENXIO;
>>
>> pages += off;
>> + err = vm_insert_range(vma, vma->vm_start, pages, page_count);
>
> Just to clarify, do we need to adjust page_count with vma->vm_pgoff as
> original code
> have not consider it and run the loop for entire range irrespective of
> vma->vm_pgoff value ?
In this instance, page_count is the size of the VMA, not the size of the
pages array itself, so as I understand things this patch is true to the
original code as-is.
Robin.
>
>> + if (err)
>> + pr_err("Remapping memory failed: %d\n", err);
>>
>> - do {
>> - int ret = vm_insert_page(vma, uaddr, *pages++);
>> - if (ret) {
>> - pr_err("Remapping memory failed: %d\n", ret);
>> - return ret;
>> - }
>> - uaddr += PAGE_SIZE;
>> - usize -= PAGE_SIZE;
>> - } while (usize > 0);
>> -
>> - return 0;
>> + return err;
>> }
>> static int arm_iommu_mmap_attrs(struct device *dev,
>> struct vm_area_struct *vma, void *cpu_addr,
>> --
>> 1.9.1
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/4] ARM: mm: permit early_memremap() to be used in paging_init()
From: Ard Biesheuvel @ 2018-12-10 16:29 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Marc Zyngier, linux-efi, Russell King, Ard Biesheuvel
In-Reply-To: <20181210162949.8597-1-ard.biesheuvel@linaro.org>
early_memremap() and early_ioremap() rely on early fixmap support,
which shares its virtual address space with kmap(), and so it is
taken down in paging_init().
In order to permit the EFI persistent memory reservation code to
use early_memremap() when called from paging_init(), move the call
to early_ioremap_reset() into paging_init(), right before the call
to early_fixmap_shutdown(), creating a window where we can add the
call to efi_apply_persistent_mem_reservations() in a subsequent patch.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/kernel/setup.c | 2 --
arch/arm/mm/mmu.c | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 375b13f7e780..7e2a936a5ed0 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1124,8 +1124,6 @@ void __init setup_arch(char **cmdline_p)
/* Memory may have been removed so recalculate the bounds. */
adjust_lowmem_bounds();
- early_ioremap_reset();
-
paging_init(mdesc);
request_standard_resources(mdesc);
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f6bf6686559d..078f82f89fe5 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -22,6 +22,7 @@
#include <asm/cputype.h>
#include <asm/sections.h>
#include <asm/cachetype.h>
+#include <asm/early_ioremap.h>
#include <asm/fixmap.h>
#include <asm/sections.h>
#include <asm/setup.h>
@@ -1628,6 +1629,7 @@ void __init paging_init(const struct machine_desc *mdesc)
memblock_set_current_limit(arm_lowmem_limit);
memblock_allow_resize();
dma_contiguous_remap();
+ early_ioremap_reset();
early_fixmap_shutdown();
devicemaps_init(mdesc);
kmap_init();
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/4] efi/arm: re-enable the memreserve table for 32-bit ARM
From: Ard Biesheuvel @ 2018-12-10 16:29 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Marc Zyngier, linux-efi, Russell King, Ard Biesheuvel
In-Reply-To: <20181210162949.8597-1-ard.biesheuvel@linaro.org>
Now that we have readded the call to efi_apply_persistent_mem_reservations
in the 32-bit ARM boot path in a place where potentially creating
many memblock reservations is permissible, re-enable the MEMRESERVE
table in the 32-bit ARM EFI stub. This brings ARM back in line with
arm64 in terms of support for efi_mem_reserve_persistent().
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/libstub/arm-stub.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 3d36142cf812..30ac0c975f8a 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -75,9 +75,6 @@ void install_memreserve_table(efi_system_table_t *sys_table_arg)
efi_guid_t memreserve_table_guid = LINUX_EFI_MEMRESERVE_TABLE_GUID;
efi_status_t status;
- if (IS_ENABLED(CONFIG_ARM))
- return;
-
status = efi_call_early(allocate_pool, EFI_LOADER_DATA, sizeof(*rsv),
(void **)&rsv);
if (status != EFI_SUCCESS) {
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] efi/arm: apply persistent memory reservations during paging_init()
From: Ard Biesheuvel @ 2018-12-10 16:29 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Marc Zyngier, linux-efi, Russell King, Ard Biesheuvel
In-Reply-To: <20181210162949.8597-1-ard.biesheuvel@linaro.org>
The new memory EFI reservation feature we introduced to allow memory
reservations to persist across kexec may trigger an unbounded number
of calls to memblock_reserve(). The memblock subsystem can deal with
this fine, but not before memblock resizing is enabled, which we can
only do after paging_init(), when the memory we reallocate the array
into is actually mapped.
So on ARM, call the broken out efi_apply_persistent_mem_reservations()
after memblock resizing has been enabled but before the early memremap
support that we rely on has been taken down.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/mm/mmu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 078f82f89fe5..8ecffb8c0c0b 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -9,6 +9,7 @@
*/
#include <linux/module.h>
#include <linux/kernel.h>
+#include <linux/efi.h>
#include <linux/errno.h>
#include <linux/init.h>
#include <linux/mman.h>
@@ -1629,6 +1630,7 @@ void __init paging_init(const struct machine_desc *mdesc)
memblock_set_current_limit(arm_lowmem_limit);
memblock_allow_resize();
dma_contiguous_remap();
+ efi_apply_persistent_mem_reservations();
early_ioremap_reset();
early_fixmap_shutdown();
devicemaps_init(mdesc);
--
2.19.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: imx6sx-sdb: Fix the reg properties for the FSL QSPI nodes
From: Schrempf Frieder @ 2018-12-10 16:28 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Rob Herring, Mark Rutland
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Schrempf Frieder, linux-spi@vger.kernel.org,
boris.brezillon@bootlin.com, broonie@kernel.org,
linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1544459182-23655-1-git-send-email-frieder.schrempf@kontron.de>
From: Frieder Schrempf <frieder.schrempf@kontron.de>
The current driver does not use the reg properties, but we will
add a new driver soon. To make sure we have a consistent scheme,
let's fix the reg properties here.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
arch/arm/boot/dts/imx6sx-sdb-reva.dts | 4 ++--
arch/arm/boot/dts/imx6sx-sdb.dts | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sx-sdb-reva.dts b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
index 9cc6ff2..344abc2 100644
--- a/arch/arm/boot/dts/imx6sx-sdb-reva.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
@@ -134,8 +134,8 @@
spi-max-frequency = <66000000>;
};
- flash1: s25fl128s@1 {
- reg = <1>;
+ flash1: s25fl128s@2 {
+ reg = <2>;
#address-cells = <1>;
#size-cells = <1>;
compatible = "spansion,s25fl128s", "jedec,spi-nor";
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dts b/arch/arm/boot/dts/imx6sx-sdb.dts
index 6dd9beb..5a39703 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb.dts
@@ -120,12 +120,12 @@
reg = <0>;
};
- flash1: n25q256a@1 {
+ flash1: n25q256a@2 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "micron,n25q256a", "jedec,spi-nor";
spi-max-frequency = <29000000>;
- reg = <1>;
+ reg = <2>;
};
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/5] ARM: dts: Add spi-[tx/rx]-bus-width for the FSL QSPI controller
From: Schrempf Frieder @ 2018-12-10 16:28 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Rob Herring, Mark Rutland, Li Yang
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Schrempf Frieder, linux-spi@vger.kernel.org,
boris.brezillon@bootlin.com, broonie@kernel.org,
linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1544459182-23655-1-git-send-email-frieder.schrempf@kontron.de>
From: Frieder Schrempf <frieder.schrempf@kontron.de>
We will move the FSL QSPI driver to the SPI framework soon. To
prepare and to make sure the full buswidth is used (as it is with
the current driver), let's add the right properties.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
arch/arm/boot/dts/imx6sx-sdb-reva.dts | 4 ++++
arch/arm/boot/dts/imx6sx-sdb.dts | 4 ++++
arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 2 ++
arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 2 ++
4 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sdb-reva.dts b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
index 344abc2..9997156 100644
--- a/arch/arm/boot/dts/imx6sx-sdb-reva.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
@@ -132,6 +132,8 @@
#size-cells = <1>;
compatible = "spansion,s25fl128s", "jedec,spi-nor";
spi-max-frequency = <66000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
};
flash1: s25fl128s@2 {
@@ -140,5 +142,7 @@
#size-cells = <1>;
compatible = "spansion,s25fl128s", "jedec,spi-nor";
spi-max-frequency = <66000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
};
};
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dts b/arch/arm/boot/dts/imx6sx-sdb.dts
index 5a39703..9acfda8 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb.dts
@@ -117,6 +117,8 @@
#size-cells = <1>;
compatible = "micron,n25q256a", "jedec,spi-nor";
spi-max-frequency = <29000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
@@ -125,6 +127,8 @@
#size-cells = <1>;
compatible = "micron,n25q256a", "jedec,spi-nor";
spi-max-frequency = <29000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <2>;
};
};
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
index 32a0723..c2c9a2a 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
@@ -176,6 +176,8 @@
#size-cells = <1>;
compatible = "micron,n25q256a";
spi-max-frequency = <29000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
};
};
diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
index 6bb7ce0..6a83f30 100644
--- a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -211,6 +211,8 @@
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <20000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
reg = <0>;
partitions@0 {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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