Re: of_reserved_mem_device_init_by_idx() returns -EINVAL if "memory-region" is missing
Hi Alexey
On 2016-06-16 18:47, Alexey Brodkin wrote:
Hi Marek,
We used to use of_reserved_mem_device_init() in such a context in GPU drivers:
>8---
/* Get the optional framebuffer memory resource */
ret = of_reserved_mem_device_init(drm->dev);
if (ret && ret != -ENODEV)
return ret;
>8---
The point is we may have a dedicated reserved memory area or may not have
(depends on a particular .dts).
Our expectation is if reserved memory area is missing then
of_reserved_mem_device_init()
just returns -ENODEV and it used to work like this.
Now with your commit 59ce4039727e "of: reserved_mem: add support for using more than
one region for given device"
behavior is different. of_reserved_mem_device_init_by_idx() has this:
>8---
target = of_parse_phandle(np, "memory-region", idx);
if (!target)
return -EINVAL;
>8---
So I'm wondering which part should be fixed:
1) of_reserved_mem itself or
2) users of of_reserved_mem_device_init()
Any thoughts?
This was my fault. The fix is already queued to linux-next, see commit
9f5a802b1d51dc80a27d828a5f7dcc8ec4a72f03 ("[media] of: reserved_mem: restore
old behavior when no region is defined"),
http://www.spinics.net/lists/linux-media/msg100972.html
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/3] dma-debug: move initialization to common code
Hi Christoph,
On 2018-04-24 16:02, Christoph Hellwig wrote:
> Most mainstream architectures are using 65536 entries, so lets stick to
> that. If someone is really desperate to override it that can still be
> done through , but I'd rather see a really good
> rationale for that.
>
> dma_debug_init is now called as a core_initcall, which for many
> architectures means much earlier, and provides dma-debug functionality
> earlier in the boot process. This should be safe as it only relies
> on the memory allocator already being available.
>
> Signed-off-by: Christoph Hellwig
Nice! Unification of this is definitely needed and solves the issues
reported some time ago:
https://patchwork.kernel.org/patch/9429637/ (arm)
https://patchwork.kernel.org/patch/9431161/ (arm64, rejected)
Acked-by: Marek Szyprowski
> ---
> arch/arm/mm/dma-mapping-nommu.c | 9 -
> arch/arm/mm/dma-mapping.c | 9 -
> arch/arm64/mm/dma-mapping.c | 10 --
> arch/c6x/kernel/dma.c | 11 ---
> arch/ia64/kernel/dma-mapping.c | 10 --
> arch/microblaze/kernel/dma.c| 11 ---
> arch/mips/mm/dma-default.c | 10 --
> arch/openrisc/kernel/dma.c | 11 ---
> arch/powerpc/kernel/dma.c | 3 ---
> arch/s390/pci/pci_dma.c | 9 -
> arch/sh/mm/consistent.c | 9 -
> arch/sparc/kernel/Makefile | 2 --
> arch/sparc/kernel/dma.c | 13 -
> arch/x86/kernel/pci-dma.c | 4
> arch/xtensa/kernel/pci-dma.c| 9 -
> include/linux/dma-debug.h | 6 --
> lib/dma-debug.c | 21 ++---
> 17 files changed, 14 insertions(+), 143 deletions(-)
> delete mode 100644 arch/sparc/kernel/dma.c
>
> diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
> index 619f24a42d09..f448a0663b10 100644
> --- a/arch/arm/mm/dma-mapping-nommu.c
> +++ b/arch/arm/mm/dma-mapping-nommu.c
> @@ -241,12 +241,3 @@ void arch_setup_dma_ops(struct device *dev, u64
> dma_base, u64 size,
> void arch_teardown_dma_ops(struct device *dev)
> {
> }
> -
> -#define PREALLOC_DMA_DEBUG_ENTRIES 4096
> -
> -static int __init dma_debug_do_init(void)
> -{
> - dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
> - return 0;
> -}
> -core_initcall(dma_debug_do_init);
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 8c398fedbbb6..c26bf83f44ca 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1165,15 +1165,6 @@ int arm_dma_supported(struct device *dev, u64 mask)
> return __dma_supported(dev, mask, false);
> }
>
> -#define PREALLOC_DMA_DEBUG_ENTRIES 4096
> -
> -static int __init dma_debug_do_init(void)
> -{
> - dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
> - return 0;
> -}
> -core_initcall(dma_debug_do_init);
> -
> #ifdef CONFIG_ARM_DMA_USE_IOMMU
>
> static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long
> attrs)
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index a96ec0181818..db01f2709842 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -508,16 +508,6 @@ static int __init arm64_dma_init(void)
> }
> arch_initcall(arm64_dma_init);
>
> -#define PREALLOC_DMA_DEBUG_ENTRIES 4096
> -
> -static int __init dma_debug_do_init(void)
> -{
> - dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
> - return 0;
> -}
> -fs_initcall(dma_debug_do_init);
> -
> -
> #ifdef CONFIG_IOMMU_DMA
> #include
> #include
> diff --git a/arch/c6x/kernel/dma.c b/arch/c6x/kernel/dma.c
> index 9fff8be75f58..31e1a9ec3a9c 100644
> --- a/arch/c6x/kernel/dma.c
> +++ b/arch/c6x/kernel/dma.c
> @@ -136,14 +136,3 @@ const struct dma_map_ops c6x_dma_ops = {
> .sync_sg_for_cpu= c6x_dma_sync_sg_for_cpu,
> };
> EXPORT_SYMBOL(c6x_dma_ops);
> -
> -/* Number of entries preallocated for DMA-API debugging */
> -#define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)
> -
> -static int __init dma_init(void)
> -{
> - dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
> -
> - return 0;
> -}
> -fs_initcall(dma_init);
> diff --git a/arch/ia64/kernel/dma-mapping.c b/arch/ia64/kernel/dma-mapping.c
> index f2d57e66fd86..7a471d8d67d4 100644
> --- a/arch/ia64/kernel/dma-mapping.c
> +++ b/arch/ia64/kernel/dma-mapping.c
> @@ -9,16 +9,6 @@ int iommu_detected __read_mostly;
> const struct dma_map_ops *dma_ops;
> EXPORT_SYMBOL(dma_ops);
>
> -#define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)
> -
> -static int __init dma_init(void)
> -{
Re: [patch V3 10/37] ARM: highmem: Switch to generic kmap atomic
Hi Thomas,
On 03.11.2020 10:27, Thomas Gleixner wrote:
> No reason having the same code in every architecture.
>
> Signed-off-by: Thomas Gleixner
> Cc: Russell King
> Cc: Arnd Bergmann
> Cc: linux-arm-ker...@lists.infradead.org
This patch landed in linux-next 20201109 as commit 2a15ba82fa6c ("ARM:
highmem: Switch to generic kmap atomic"). However it causes a following
warning on my test boards (Samsung Exynos SoC based):
Run /sbin/init as init process
INIT: version 2.88 booting
[ cut here ]
WARNING: CPU: 3 PID: 120 at mm/highmem.c:502
kunmap_local_indexed+0x194/0x1d0
Modules linked in:
CPU: 3 PID: 120 Comm: init Not tainted 5.10.0-rc2-00010-g2a15ba82fa6c #1924
Hardware name: Samsung Exynos (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xb4/0xd4)
[] (dump_stack) from [] (__warn+0x98/0x104)
[] (__warn) from [] (warn_slowpath_fmt+0xb0/0xb8)
[] (warn_slowpath_fmt) from []
(kunmap_local_indexed+0x194/0x1d0)
[] (kunmap_local_indexed) from []
(remove_arg_zero+0xa0/0x158)
[] (remove_arg_zero) from [] (load_script+0x250/0x318)
[] (load_script) from [] (bprm_execve+0x3d0/0x930)
[] (bprm_execve) from []
(do_execveat_common+0x174/0x184)
[] (do_execveat_common) from [] (sys_execve+0x30/0x38)
[] (sys_execve) from [] (ret_fast_syscall+0x0/0x28)
Exception stack(0xc4561fa8 to 0xc4561ff0)
1fa0: b6f2bab8 bef7dac4 bef7dac4 bef7d8fc 004b9b58
bef7dac8
1fc0: b6f2bab8 bef7dac4 bef7d8fc 000b 004b8000 004bac44 bef7da3c
bef7d8dc
1fe0: 002f bef7d89c b6d6dc74 b6d6d65c
irq event stamp: 1283
hardirqs last enabled at (1293): [] console_unlock+0x430/0x6b0
hardirqs last disabled at (1302): [] console_unlock+0x428/0x6b0
softirqs last enabled at (1282): [] __do_softirq+0x528/0x674
softirqs last disabled at (1269): [] irq_exit+0x1dc/0x1e8
---[ end trace 6f32a2fb4294655f ]---
I can do more tests to help fixing this issue. Just let me know what to do.
...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH net 1/1] net: stmmac: check fwnode for phy device before scanning for phy
On 05.04.2023 12:07, Shahab Vahedi wrote:
> On 4/5/23 11:39, Michael Sit Wei Hong wrote:
>> Some DT devices already have phy device configured in the DT/ACPI.
>> Current implementation scans for a phy unconditionally even though
>> there is a phy listed in the DT/ACPI and already attached.
>>
>> We should check the fwnode if there is any phy device listed in
>> fwnode and decide whether to scan for a phy to attach to.y
>>
>> Reported-by: Martin Blumenstingl
>> Fixes: fe2cfbc96803 ("net: stmmac: check if MAC needs to attach to a PHY")
>> Signed-off-by: Michael Sit Wei Hong
>> ---
> Works fine on ARC HSDK board.
> Tested-by: Shahab Vahedi
Tested-by: Marek Szyprowski
Works fine on Khadas VIM3, Odroid-C4 and Odroid-M1.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
