[ Upstream commit e330fb1459 ]
Rob suggests to move of_net.c from under drivers/of/ somewhere
to the networking code.
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5d05b811b5 upstream.
The cells_name field of of_phandle_iterator might be NULL. Use the
phandle name instead. With this change instead of:
OF: /soc/pinctrl@1000000: (null) = 3 found 2
We get:
OF: /soc/pinctrl@1000000: phandle pinctrl@1000000 needs 3, found 2
Which is a more helpful messages making DT debugging easier.
In this particular example the phandle name looks like duplicate of the
same node name. But note that the first node is the parent node
(it->parent), while the second is the phandle target (it->node). They
happen to be the same in the case that triggered this improvement. See
commit 72cb4c48a4 ("arm64: dts: qcom: ipq6018: Fix gpio-ranges
property").
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/f6a68e0088a552ea9dfd4d8e3b5b586d92594738.1640881913.git.baruch@tkos.co.il
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit da17d6905d ]
In commit 8a5a75e5e9 ("of/fdt: Make sure no-map does not remove
already reserved regions") we returned -EBUSY when trying to mark
regions as no-map when they intersect with reserved memory. The goal was
to find bad no-map reserved memory DT nodes that would unmap the kernel
text/data sections.
The problem is the reserved memory check will still trigger if the DT
has a /memreserve/ that completely subsumes the no-map memory carveouts
in the reserved memory node _and_ that region is also not part of the
memory reg property. For example in sc7180.dtsi we have the following
reserved-memory and memory node:
memory@80000000 {
/* We expect the bootloader to fill in the size */
reg = <0 0x80000000 0 0>;
};
smem_mem: memory@80900000 {
reg = <0x0 0x80900000 0x0 0x200000>;
no-map;
};
and the memreserve filled in by the bootloader is
/memreserve/ 0x80800000 0x400000;
while the /memory node is transformed into
memory@80000000 {
/* The bootloader fills in the size, and adds another region */
reg = <0 0x80000000 0 0x00800000>,
<0 0x80c00000 0 0x7f200000>;
};
The smem region is doubly reserved via /memreserve/ and by not being
part of the /memory reg property. This leads to the following warning
printed at boot.
OF: fdt: Reserved memory: failed to reserve memory for node 'memory@80900000': base 0x0000000080900000, size 2 MiB
Otherwise nothing really goes wrong because the smem region is not going
to be mapped by the kernel's direct linear mapping given that it isn't
part of the memory node. Therefore, let's only consider this to be a
problem if we're trying to mark a region as no-map and it is actually
memory that we're intending to keep out of the kernel's direct mapping
but it's already been reserved.
Acked-by: Mike Rapoport <rppt@kernel.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Nicolas Boichat <drinkcat@chromium.org>
Cc: Quentin Perret <qperret@google.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Fixes: 8a5a75e5e9 ("of/fdt: Make sure no-map does not remove already reserved regions")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220107194233.2793146-1-swboyd@chromium.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 94a4950a4a ]
The cell_count field of of_phandle_iterator is the number of cells we
expect in the phandle arguments list when cells_name is missing. The
error message should show the number of cells we actually see.
Fixes: af3be70a32 ("of: Improve of_phandle_iterator_next() error message")
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/96519ac55be90a63fa44afe01480c30d08535465.1640881913.git.baruch@tkos.co.il
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8347b41748 ]
Currently, we parse the "linux,usable-memory-range" property in
early_init_dt_scan_chosen(), to obtain the specified memory range of the
crash kernel. We then reserve the required memory after
early_init_dt_scan_memory() has identified all available physical memory.
Because the two pieces of code are separated far, the readability and
maintainability are reduced. So bring them together.
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
(change the prototype of early_init_dt_check_for_usable_mem_range(), in
order to use it outside)
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Acked-by: John Donnelly <john.p.donnelly@oracle.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
To: devicetree@vger.kernel.org
To: linux-efi@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9fd4cf5d35 ]
If an architecture does not support 64 bit dma addresses then testing
for an expected dma address >= 0x100000000 will fail.
Fixes: e0d072782c ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset")
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211212221852.233295-1-frowand.list@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a8d61a9112 ]
The struct device variable "dev_bogus" was triggering this warning
on a PowerPC build:
drivers/of/unittest.c: In function 'of_unittest_dma_ranges_one.constprop':
[...] >> The frame size of 1424 bytes is larger than 1024 bytes
[-Wframe-larger-than=]
This variable is now dynamically allocated.
Fixes: e0d072782c ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Frank Rowand <frank.rowand@sony.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211210184636.7273-2-jim2101024@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e85860e5bc ]
The console message text for gpio hog errors does not match
what unittest expects.
Fixes: f4056e705b ("of: unittest: add overlay gpio test to catch gpio hog problem")
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
Link: https://lore.kernel.org/r/20211029013225.2048695-1-frowand.list@gmail.com
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vladimir Zapolskiy reports:
Commit a7259df767 ("memblock: make memblock_find_in_range method
private") invokes a kernel panic while running kmemleak on OF platforms
with nomaped regions:
Unable to handle kernel paging request at virtual address fff000021e00000
[...]
scan_block+0x64/0x170
scan_gray_list+0xe8/0x17c
kmemleak_scan+0x270/0x514
kmemleak_write+0x34c/0x4ac
The memory allocated from memblock is registered with kmemleak, but if
it is marked MEMBLOCK_NOMAP it won't have linear map entries so an
attempt to scan such areas will fault.
Ideally, memblock_mark_nomap() would inform kmemleak to ignore
MEMBLOCK_NOMAP memory, but it can be called before kmemleak interfaces
operating on physical addresses can use __va() conversion.
Make sure that functions that mark allocated memory as MEMBLOCK_NOMAP
take care of informing kmemleak to ignore such memory.
Link: https://lore.kernel.org/all/8ade5174-b143-d621-8c8e-dc6a1898c6fb@linaro.org
Link: https://lore.kernel.org/all/c30ff0a2-d196-c50d-22f0-bd50696b1205@quicinc.com
Fixes: a7259df767 ("memblock: make memblock_find_in_range method private")
Reported-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Tested-by: Qian Cai <quic_qiancai@quicinc.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Configurations with both CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM=m
are allowed by Kconfig because the 'depends on !DRM_SIMPLEDRM' dependency
does not disallow FB_SIMPLE as long as SIMPLEDRM is not built-in. This
can however result in a build failure when cfb_fillrect() etc are then
also in loadable modules:
x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x1f8): undefined reference to `cfb_fillrect'
x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x200): undefined reference to `cfb_copyarea'
x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x208): undefined reference to `cfb_imageblit'
To work around this, change FB_SIMPLE to be a 'tristate' symbol,
which still allows both to be =m together, but not one of them to
be =y if the other one is =m. If a distro kernel picks this
configuration, it can be determined by local policy which of
the two modules gets loaded. The 'of_chosen' export is needed
as this is the first loadable module referencing it.
Alternatively, the Kconfig dependency could be changed to
'depends on DRM_SIMPLEDRM=n', which would forbid the configuration
with both drivers.
Fixes: 11e8f5fd22 ("drm: Add simpledrm driver")
Acked-by: Rob Herring <robh@kernel.org> # for drivers/of/
Link: https://lore.kernel.org/all/20210721151839.2484245-1-arnd@kernel.org/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch> # fbdev support
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Borislav Petkov <bp@suse.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: <stable@vger.kernel.org> # v5.14+
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210928145243.1098064-1-arnd@kernel.org
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
of_dma_set_restricted_buffer fails to handle negative return values from
of_property_count_elems_of_size, e.g. when the property does not exist.
This results in an attempt to assign a non-existent reserved memory
region to the device and a warning being printed. Fix the condition to
take negative values into account.
Fixes: f3cfd136ae ("of: restricted dma: Don't fail device probe on rmem init failure")
Cc: Will Deacon <will@kernel.org>
Signed-off-by: David Brazdil <dbrazdil@google.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210917131423.2760155-1-dbrazdil@google.com
Signed-off-by: Rob Herring <robh@kernel.org>
This reverts commit cf4b94c853.
Some PHYs pointed to by "phy-handle" will never bind to a driver until a
consumer attaches to it. And when the consumer attaches to it, they get
forcefully bound to a generic PHY driver. In such cases, parsing the
phy-handle property and creating a device link will prevent the consumer
from ever probing. We don't want that. So revert support for
"phy-handle" property until we come up with a better mechanism for
binding PHYs to generic drivers before a consumer tries to attach to it.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210915081933.485112-1-saravanak@google.com
Signed-off-by: Rob Herring <robh@kernel.org>
Andre reported fw_devlink=on breaking OLPC XO-1.5 [1].
OLPC XO-1.5 is an X86 system that uses a mix of ACPI and OF to populate
devices. The root cause seems to be ISA devices not setting their fwnode
field. But trying to figure out how to fix that doesn't seem worth the
trouble because the OLPC devicetree is very sparse/limited and fw_devlink
only adds the links causing this issue. Considering that there aren't many
users of OF in an X86 system, simply fw_devlink DT support for X86.
[1] - https://lore.kernel.org/lkml/3c1f2473-92ad-bfc4-258e-a5a08ad73dd0@web.de/
Fixes: ea718c6990 ("Revert "Revert "driver core: Set fw_devlink=on by default""")
Signed-off-by: Saravana Kannan <saravanak@google.com>
Cc: Andre Muller <andre.muller@web.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Andre Müller <andre.muller@web.de>
Link: https://lore.kernel.org/r/20210910011446.3208894-1-saravanak@google.com
Signed-off-by: Rob Herring <robh@kernel.org>
Pull swiotlb updates from Konrad Rzeszutek Wilk:
"A new feature called restricted DMA pools. It allows SWIOTLB to
utilize per-device (or per-platform) allocated memory pools instead of
using the global one.
The first big user of this is ARM Confidential Computing where the
memory for DMA operations can be set per platform"
* 'stable/for-linus-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb: (23 commits)
swiotlb: use depends on for DMA_RESTRICTED_POOL
of: restricted dma: Don't fail device probe on rmem init failure
of: Move of_dma_set_restricted_buffer() into device.c
powerpc/svm: Don't issue ultracalls if !mem_encrypt_active()
s390/pv: fix the forcing of the swiotlb
swiotlb: Free tbl memory in swiotlb_exit()
swiotlb: Emit diagnostic in swiotlb_exit()
swiotlb: Convert io_default_tlb_mem to static allocation
of: Return success from of_dma_set_restricted_buffer() when !OF_ADDRESS
swiotlb: add overflow checks to swiotlb_bounce
swiotlb: fix implicit debugfs declarations
of: Add plumbing for restricted DMA pool
dt-bindings: of: Add restricted DMA pool
swiotlb: Add restricted DMA pool initialization
swiotlb: Add restricted DMA alloc/free support
swiotlb: Refactor swiotlb_tbl_unmap_single
swiotlb: Move alloc_size to swiotlb_find_slots
swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
swiotlb: Update is_swiotlb_active to add a struct device argument
swiotlb: Update is_swiotlb_buffer to add a struct device argument
...
Merge misc updates from Andrew Morton:
"173 patches.
Subsystems affected by this series: ia64, ocfs2, block, and mm (debug,
pagecache, gup, swap, shmem, memcg, selftests, pagemap, mremap,
bootmem, sparsemem, vmalloc, kasan, pagealloc, memory-failure,
hugetlb, userfaultfd, vmscan, compaction, mempolicy, memblock,
oom-kill, migration, ksm, percpu, vmstat, and madvise)"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (173 commits)
mm/madvise: add MADV_WILLNEED to process_madvise()
mm/vmstat: remove unneeded return value
mm/vmstat: simplify the array size calculation
mm/vmstat: correct some wrong comments
mm/percpu,c: remove obsolete comments of pcpu_chunk_populated()
selftests: vm: add COW time test for KSM pages
selftests: vm: add KSM merging time test
mm: KSM: fix data type
selftests: vm: add KSM merging across nodes test
selftests: vm: add KSM zero page merging test
selftests: vm: add KSM unmerge test
selftests: vm: add KSM merge test
mm/migrate: correct kernel-doc notation
mm: wire up syscall process_mrelease
mm: introduce process_mrelease system call
memblock: make memblock_find_in_range method private
mm/mempolicy.c: use in_task() in mempolicy_slab_node()
mm/mempolicy: unify the create() func for bind/interleave/prefer-many policies
mm/mempolicy: advertise new MPOL_PREFERRED_MANY
mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY
...
There are a lot of uses of memblock_find_in_range() along with
memblock_reserve() from the times memblock allocation APIs did not exist.
memblock_find_in_range() is the very core of memblock allocations, so any
future changes to its internal behaviour would mandate updates of all the
users outside memblock.
Replace the calls to memblock_find_in_range() with an equivalent calls to
memblock_phys_alloc() and memblock_phys_alloc_range() and make
memblock_find_in_range() private method of memblock.
This simplifies the callers, ensures that (unlikely) errors in
memblock_reserve() are handled and improves maintainability of
memblock_find_in_range().
Link: https://lkml.kernel.org/r/20210816122622.30279-1-rppt@kernel.org
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> [arm64]
Acked-by: Kirill A. Shutemov <kirill.shtuemov@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ACPI]
Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Acked-by: Nick Kossifidis <mick@ics.forth.gr> [riscv]
Tested-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On ia64/allmodconfig:
drivers/of/fdt.c:609:20: error: conflicting types for 'reserve_elfcorehdr'; have 'void(void)'
609 | static void __init reserve_elfcorehdr(void)
| ^~~~~~~~~~~~~~~~~~
arch/ia64/include/asm/meminit.h:43:12: note: previous declaration of 'reserve_elfcorehdr' with type 'int(u64 *, u64 *)' {aka 'int(long long unsigned int *, long long unsigned int *)'}
43 | extern int reserve_elfcorehdr(u64 *start, u64 *end);
| ^~~~~~~~~~~~~~~~~~
Fix this by prefixing the FDT function name with "fdt_".
Fixes: f7e7ce93aa ("of: fdt: Add generic support for handling elf core headers property")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/f6eabbbce0fba6da3da0264c1e1cf23c01173999.1629884393.git.geert+renesas@glider.be
Signed-off-by: Rob Herring <robh@kernel.org>
Add support for handling the "linux,usable-memory-range" property in the
"/chosen" node to the FDT core code. This can co-exist safely with the
architecture-specific handling, until the latter has been removed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/3bd69bada93ee59b7d23c38b3527fc1654e19343.1628670468.git.geert+renesas@glider.be
There are two methods to specify the location of the elf core headers:
using the "elfcorehdr=" kernel parameter, as handled by generic code in
kernel/crash_dump.c, or using the "linux,elfcorehdr" property under the
"/chosen" node in the Device Tree, as handled by architecture-specific
code in arch/arm64/mm/init.c.
Extend support for "linux,elfcorehdr" to all platforms supporting DT by
adding platform-agnostic handling for handling this property to the FDT
core code. This can co-exist safely with the architecture-specific
handling, until the latter has been removed.
This requires moving the call to of_scan_flat_dt() up, as the code
scanning the "/chosen" node now needs to be aware of the values of
"#address-cells" and "#size-cells".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/c7e46e50aaf87ef49bdaa61358d25b122f32b7df.1628670468.git.geert+renesas@glider.be
Trying to boot without SYSFS, but with OF_DYNAMIC quickly
results in a crash:
[ 0.088460] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070
[...]
[ 0.103927] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc3 #4179
[ 0.105810] Hardware name: linux,dummy-virt (DT)
[ 0.107147] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
[ 0.108876] pc : kernfs_find_and_get_ns+0x3c/0x7c
[ 0.110244] lr : kernfs_find_and_get_ns+0x3c/0x7c
[...]
[ 0.134087] Call trace:
[ 0.134800] kernfs_find_and_get_ns+0x3c/0x7c
[ 0.136054] safe_name+0x4c/0xd0
[ 0.136994] __of_attach_node_sysfs+0xf8/0x124
[ 0.138287] of_core_init+0x90/0xfc
[ 0.139296] driver_init+0x30/0x4c
[ 0.140283] kernel_init_freeable+0x160/0x1b8
[ 0.141543] kernel_init+0x30/0x140
[ 0.142561] ret_from_fork+0x10/0x18
While not having sysfs isn't a very common option these days,
it is still expected that such configuration would work.
Paper over it by bailing out from __of_attach_node_sysfs() if
CONFIG_SYSFS isn't enabled.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210820144722.169226-1-maz@kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
If CONFIG_DMA_RESTRICTED_POOL=n then probing a device with a reference
to a "restricted-dma-pool" will fail with a reasonably cryptic error:
| pci-host-generic: probe of 10000.pci failed with error -22
Rework of_dma_set_restricted_buffer() so that it does not cause probing
failure and instead either returns early if CONFIG_DMA_RESTRICTED_POOL=n
or emits a diagnostic if the reserved DMA pool fails to initialise.
Cc: Claire Chang <tientzu@chromium.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Rob observes that:
| of_dma_set_restricted_buffer() [...] should also be moved to
| of/device.c. There's no reason for it to be in of/address.c. It has
| nothing to do with address parsing.
Move it to of/device.c, as he suggests.
Cc: Claire Chang <tientzu@chromium.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Robin Murphy <robin.murphy@arm.com>
Suggested-by: Rob Herring <robh+dt@kernel.org>
Link: https://lore.kernel.org/r/CAL_JsqJ7ROWWJX84x2kEex9NQ8G+2=ybRuNOobX+j8bjZzSemQ@mail.gmail.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Commit 41a9ada3e6 ("of/fdt: mark hotpluggable memory") introduced
two (for systems with and without memblock) weak versions of
early_init_dt_mark_hotplug_memory_arch(), that could be overridden by an
architecture-specific version. However, no overrides ever emerged.
Later, commit aca52c3983 ("mm: remove CONFIG_HAVE_MEMBLOCK")
removed the non-memblock version.
Remove early_init_dt_mark_hotplug_memory_arch(), and replace it by a
direct call to memblock_mark_hotplug().
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/1a61f75ec50d3c2922fcdbe33337266a58a4125f.1628671960.git.geert+renesas@glider.be
Signed-off-by: Rob Herring <robh@kernel.org>
Fix the below warning:
drivers/of/fdt.c:196:4: warning: Value stored to 'pprev' is never read
[clang-analyzer-deadcode.DeadStores]
pprev = &pp->next;
^ ~~~~~~~~~
Signed-off-by: Ohhoon Kwon <ohoono.kwon@samsung.com>
Link: https://lore.kernel.org/r/20210803101309.904-1-ohoono.kwon@samsung.com
Signed-off-by: Rob Herring <robh@kernel.org>
When CONFIG_OF_ADDRESS=n, of_dma_set_restricted_buffer() returns -ENODEV
and breaks the boot for sparc[64] machines. Return 0 instead, since the
function is essentially a glorified NOP in this configuration.
Cc: Claire Chang <tientzu@chromium.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Claire Chang <tientzu@chromium.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210702030807.GA2685166@roeck-us.net
Fixes: fec9b62509 ("of: Add plumbing for restricted DMA pool")
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad@kernel.org>
While unflattening the device tree, we try to populate dt nodes and
properties into tree-shaped data structure.
In populate_properties function, pprev is initially set to
&np->properties, and then updated to &pp->next.
In both scenarios *pprev is NULL, since the memory area that we are
allocating from is initially zeroed.
I tested the code as below, and it showed that BUG was never called.
- if (!dryrun)
+ if (!dryrun) {
+ if (*pprev)
+ BUG();
*pprev = NULL;
+ }
Let's remove unnecessary code.
Signed-off-by: Ohhoon Kwon <ohoono.kwon@samsung.com>
Link: https://lore.kernel.org/r/20210701140457epcms1p2cc43a7c62150f012619feab913f017af@epcms1p2
Signed-off-by: Rob Herring <robh@kernel.org>
In __of_get_next_child function, loop iteration for getting next node is
unnecessary.
for loop is already checking if next is NULL or not, and
of_node_get(next) always returns next itself.
Therefore checking return value in the if clause always evaluates to
true, and thus it always breaks out from for loop in the first iteration.
Remove the unnecessary for loop for readability.
I tested the code as below, and it showed that BUG was never called.
- for (; next; next = next->sibling)
+ for (; next; next = next->sibling) {
if (of_node_get(next))
break;
+ BUG();
+ }
Signed-off-by: Ohhoon Kwon <ohoono.kwon@samsung.com>
Link: https://lore.kernel.org/r/20210701140328epcms1p85149318b6c18fa18b3c7c8e966c14db0@epcms1p8
Signed-off-by: Rob Herring <robh@kernel.org>
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang <tientzu@chromium.org>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Will Deacon <will@kernel.org>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
If building with OF Kconfig disabled, this can lead to errors for
drivers utilizing of_add_property(). Add a stub for the add API, as
it exists for the remove variant as well, and to avoid compliation
issues. Also, export this API so that it can be used by modules.
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/1625908395-5498-5-git-send-email-wcheng@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- Refine reserved memory nomap handling
- Merge some PCI and non-PCI address handling implementations
- Simplify of_address.h header ifdefs
- Improve printk handling of some 64-bit types
- Convert Arm ccree, Zynq FPGA, ZynqMP RTC, Arm VIC, adi,adv7511, TI
AM56 PCI, Aspeed I2C, arm,sbsa-gwdt, MTD physmap, virtio-mmio, Arm
SCMI, Arm/Amlogic SCPI, TI OMAP mailbox, NXP pcf8563/pcf85263/pcf85363,
Mediatek RNG, Arm SCU, Arm TWD timer, Broadcom iProc PWM, Renesas TPU,
Tegra20 EMC, MDIO GPIO, renesas,r9a06g032-sysctrl, renesas,emev2-smu,
sysc-rmobile, linaro,optee-tz, and TI SCI bindings to DT schema
- Convert mux and mux controller bindings to schema. This includes MDIO
IIO, and I2C muxes.
- Add Arm PL031 RTC binding schema
- Add vendor prefixes for StarFive Technology Co. Ltd. and Insignal Ltd
- Fix some stale doc references
- Remove stale property-units.txt. Superseded by schema in dt-schema
repo.
- Fixes for 'unevaluatedProperties' handling (enabled with experimental
json-schema support)
- Drop redundant usage of minItems and maxItems across the tree
- Update some examples to use bindings with a schema
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEEktVUI4SxYhzZyEuo+vtdtY28YcMFAmDfNTsQHHJvYmhAa2Vy
bmVsLm9yZwAKCRD6+121jbxhwx/jD/0TG5A5clgwEA/0wKTLUK0OmRhTS4T9AjD2
NIgs+74YztwP1c49u6SXmSCD1wfyHl1dznmvXUn/gD9838gwYjHH4eZgG5weOwOy
hQgEhUqZ3AJF24wEDAfkQX7KCh9rxO1Vifx+2ER+DXCc65kBxbwdBSUSgWSkN/fj
UHRENdW37ORw4WLXELGYDRegvLktzCbPqwPWUBJy8+9or1/r2ZFN5Or6gG1J7HR5
jGiiKyB5O5E1GBtiCQaFoGl+uQG5/X2aSb7AMYbMnOTP+fr9YiTbcTjKwoMMurJW
T56YUse0QZ7yK5umUMV17A2urrOg9Nnk7kj5Sf63UkOwVY5Xjx/TqIwBPZGXUTlK
RdSIZXzzdv491pem1sHty6TjX3NFIe81aR9p7CZIigOa9AXj5PMcVHflq3SUDSuQ
nCg2qf7E73307w5PNLSbkEFkR/g341pqwvwMmRDb9a68ZBwhylKKVdV0GzAdea8P
ez1R0hJMJ/y5DqdC1KXOjLOR6zX+a3daLTPLsPKXeeKMsI/U4BXF3s5aoxBavkzU
SLiZynost28oTlVX7K2fl4r7WocyMj4htywqerfeJVry+FVopFVNcwb/zowRSOpd
o9xqpSXMXzBDB5eSQR331mOrUU5SxKhISmofH3U+MvF9D2/yNB1qMhMSAN9DBzOl
mofZZWSIzg==
=MDNZ
-----END PGP SIGNATURE-----
Merge tag 'devicetree-for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull devicetree updates from Rob Herring:
- Refine reserved memory nomap handling
- Merge some PCI and non-PCI address handling implementations
- Simplify of_address.h header ifdefs
- Improve printk handling of some 64-bit types
- Convert adi,adv7511, Arm ccree, Arm SCMI, Arm SCU, Arm TWD timer, Arm
VIC, arm,sbsa-gwdt, Arm/Amlogic SCPI, Aspeed I2C, Broadcom iProc PWM,
linaro,optee-tz, MDIO GPIO, Mediatek RNG, MTD physmap, NXP
pcf8563/pcf85263/pcf85363, Renesas TPU, renesas,emev2-smu,
renesas,r9a06g032-sysctrl, sysc-rmobile, Tegra20 EMC, TI AM56 PCI, TI
OMAP mailbox, TI SCI bindings, virtio-mmio, Zynq FPGA, and ZynqMP RTC
to DT schema
- Convert mux and mux controller bindings to schema. This includes MDIO
IIO, and I2C muxes.
- Add Arm PL031 RTC binding schema
- Add vendor prefixes for StarFive Technology Co. Ltd. and Insignal Ltd
- Fix some stale doc references
- Remove stale property-units.txt. Superseded by schema in dt-schema
repo.
- Fixes for 'unevaluatedProperties' handling (enabled with experimental
json-schema support)
- Drop redundant usage of minItems and maxItems across the tree
- Update some examples to use bindings with a schema
* tag 'devicetree-for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (83 commits)
dt-bindings: Fix 'unevaluatedProperties' errors in DT graph users
dt-bindings: display: renesas,du: Fix 'ports' reference
dt-bindings: media: adv7180: Add missing video-interfaces.yaml reference
dt-bindings: crypto: ccree: Convert to json-schema
dt-bindings: fpga: zynq: convert bindings to YAML
dt-bindings: rtc: zynqmp: convert bindings to YAML
dt-bindings: interrupt-controller: Convert ARM VIC to json-schema
of: of_reserved_mem: mark nomap memory instead of removing
of: of_reserved_mem: only call memblock_free for normal reserved memory
dt-bindings: Drop redundant minItems/maxItems
dt-bindings: spmi: Correct 'reg' schema
of: reserved-memory: Add stub for RESERVEDMEM_OF_DECLARE()
dt-bindings: clk: vc5: Fix example
dt-bindings: timer: renesas,tmu: add r8a779a0 TMU support
dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
dt-bindings: PCI: ti,am65: Convert PCIe host/endpoint mode dt-bindings to YAML
of: Remove superfluous casts when printing u64 values
of: Fix truncation of memory sizes on 32-bit platforms
dt-bindings: rtc: nxp,pcf8563: Absorb pcf85263/pcf85363 bindings
dt-bindings: pwm: Use examples with documented/matching schema
...
Since commit 86588296ac ("fdt: Properly handle "no-map" field in the memory region"),
nomap memory is changed to call memblock_mark_nomap() instead of
memblock_remove(). But it only changed the reserved memory with fixed
addr and size case in early_init_dt_reserve_memory_arch(), not
including the dynamical allocation by size case in
early_init_dt_alloc_reserved_memory_arch().
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: Quentin Perret <qperret@google.com>
Link: https://lore.kernel.org/r/20210611131153.3731147-2-aisheng.dong@nxp.com
Signed-off-by: Rob Herring <robh@kernel.org>
For nomap case, the memory block will be removed by memblock_remove()
in early_init_dt_alloc_reserved_memory_arch(). So it's meaningless to
call memblock_free() on error path.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Link: https://lore.kernel.org/r/20210611131153.3731147-1-aisheng.dong@nxp.com
Signed-off-by: Rob Herring <robh@kernel.org>
Variable "size" has type "phys_addr_t", which can be either 32-bit or
64-bit on 32-bit systems, while "unsigned long" is always 32-bit on
32-bit systems. Hence the cast in
(unsigned long)size / SZ_1M
may truncate a 64-bit size to 32-bit, as casts have a higher operator
precedence than divisions.
Fix this by inverting the order of the cast and division, which should
be safe for memory blocks smaller than 4 PiB. Note that the division is
actually a shift, as SZ_1M is a power-of-two constant, hence there is no
need to use div_u64().
While at it, use "%lu" to format "unsigned long".
Fixes: e8d9d1f548 ("drivers: of: add initialization code for static reserved memory")
Fixes: 3f0c820664 ("drivers: of: add initialization code for dynamic reserved memory")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/4a1117e72d13d26126f57be034c20dac02f1e915.1623835273.git.geert+renesas@glider.be
Signed-off-by: Rob Herring <robh@kernel.org>
The only place of_iommu.h is needed is in drivers/of/device.c. Remove it
from everywhere else.
Cc: Will Deacon <will@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Yong Wu <yong.wu@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: iommu@lists.linux-foundation.org
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20210527193710.1281746-2-robh@kernel.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
of_address_to_resource() and of_pci_address_to_resource() are almost the
same except the former takes an index and the latter takes a BAR number.
Now that __of_get_address() can take either one, refactor the functions
to use a common implementation.
Cc: Frank Rowand <frowand.list@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210527194547.1287934-5-robh@kernel.org
Convert address.c to use IS_ENABLED() instead of ifdefs for the
public PCI functions. This simplifies the ifdefs in of_address.h.
Cc: Frank Rowand <frowand.list@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210527194547.1287934-4-robh@kernel.org
of_get_address() and of_get_pci_address() are the same implementation
except of_get_pci_address() takes the PCI BAR number rather than an
index. Modify the of_get_address() implementation to work on either
index or BAR and provide wrapper functions for the existing functions.
Cc: Frank Rowand <frowand.list@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210527194547.1287934-3-robh@kernel.org
fdt_init_reserved_mem() and fdt_reserved_mem_save_node() are private to
the DT code, so move there declarations to of_private.h. There's no need
for the dummy functions as CONFIG_OF_RESERVED_MEM is always enabled for
CONFIG_OF_EARLY_FLATTREE.
Cc: Frank Rowand <frowand.list@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210527193841.1284169-1-robh@kernel.org
Reserved memory regions can be used for more than just DMA regions, so
only enabling on DMA_DECLARE_COHERENT (via HAS_DMA) or DMA_CMA is wrong.
This effectively doesn't matter except for the few cases arches select
NO_DMA.
At least, these users of RESERVEDMEM_OF_DECLARE depend on reserved memory
support:
arch/riscv/mm/init.c:RESERVEDMEM_OF_DECLARE(elfcorehdr, "linux,elfcorehdr", elfcore_hdr_setup);
drivers/memory/tegra/tegra210-emc-table.c:RESERVEDMEM_OF_DECLARE(tegra210_emc_table, "nvidia,tegra210-emc-table",
drivers/soc/fsl/qbman/bman_ccsr.c:RESERVEDMEM_OF_DECLARE(bman_fbpr, "fsl,bman-fbpr", bman_fbpr);
drivers/soc/fsl/qbman/qman_ccsr.c:RESERVEDMEM_OF_DECLARE(qman_fqd, "fsl,qman-fqd", qman_fqd);
drivers/soc/fsl/qbman/qman_ccsr.c:RESERVEDMEM_OF_DECLARE(qman_pfdr, "fsl,qman-pfdr", qman_pfdr);
Let's simplify things and enable OF_RESERVED_MEM when OF_EARLY_FLATTREE is
enabled.
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210527223217.1572631-1-robh@kernel.org
Variable ret is set to zero but this value is never read as it is
overwritten with a new value later on, hence it is a redundant
assignment and can be removed.
Cleans up the following clang-analyzer warning:
drivers/of/overlay.c:1197:2: warning: Value stored to 'ret' is never
read [clang-analyzer-deadcode.DeadStores].
drivers/of/overlay.c:1026:2: warning: Value stored to 'ret' is never
read [clang-analyzer-deadcode.DeadStores].
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/1619347258-55002-1-git-send-email-jiapeng.chong@linux.alibaba.com
Signed-off-by: Rob Herring <robh@kernel.org>
