kernel/linux.git/drivers/of/of_private.h, branch v5.19

of: kobj: make of_node_is_(initialized|attached) parameters const

2021-10-20T18:37:25+00:00

of_node_is_initialized() and of_node_is_attached() don't modify the node objects passed to them, so those parameters should be const. Signed-off-by: Nathan Lynch Link: https://lore.kernel.org/r/20211014173023.2117799-1-nathanl@linux.ibm.com Signed-off-by: Rob Herring

of: remove duplicate declarations of __of_*_sysfs() functions

2021-10-06T19:14:38+00:00

When CONFIG_OF_KOBJ was introduced in commit b56b5528f5b3 ("of: make kobject and bin_attribute support configurable") and #ifdef-ed versions of these declarations got added, the originals didn't get removed. Fixes: b56b5528f5b3 ("of: make kobject and bin_attribute support configurable") Signed-off-by: Zev Weiss Link: https://lore.kernel.org/r/20211006061943.8472-1-zev@bewilderbeest.net Signed-off-by: Rob Herring

of: Move reserved memory private function declarations

2021-06-03T01:59:28+00:00

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 Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20210527193841.1284169-1-robh@kernel.org

of: unittest: overlay: ensure proper alignment of copied FDT

2021-04-08T21:38:47+00:00

The Devicetree standard specifies an 8 byte alignment of the FDT. Code in libfdt expects this alignment for an FDT image in memory. kmemdup() returns 4 byte alignment on openrisc. Replace kmemdup() with kmalloc(), align pointer, memcpy() to get proper alignment. The 4 byte alignment exposed a related bug which triggered a crash on openrisc with: commit 79edff12060f ("scripts/dtc: Update to upstream version v1.6.0-51-g183df9e9c2b9") as reported in: https://lore.kernel.org/lkml/20210327224116.69309-1-linux@roeck-us.net/ Reported-by: Guenter Roeck Signed-off-by: Frank Rowand Link: https://lore.kernel.org/r/20210408204508.2276230-1-frowand.list@gmail.com Signed-off-by: Rob Herring

dma-mapping: introduce DMA range map, supplanting dma_pfn_offset

2020-09-17T16:43:56+00:00

The new field 'dma_range_map' in struct device is used to facilitate the use of single or multiple offsets between mapping regions of cpu addrs and dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only capable of holding a single uniform offset and had no region bounds checking. The function of_dma_get_range() has been modified so that it takes a single argument -- the device node -- and returns a map, NULL, or an error code. The map is an array that holds the information regarding the DMA regions. Each range entry contains the address offset, the cpu_start address, the dma_start address, and the size of the region. of_dma_configure() is the typical manner to set range offsets but there are a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel driver code. These cases now invoke the function dma_direct_set_offset(dev, cpu_addr, dma_addr, size). Signed-off-by: Jim Quinlan [hch: various interface cleanups] Signed-off-by: Christoph Hellwig Reviewed-by: Mathieu Poirier Tested-by: Mathieu Poirier Tested-by: Nathan Chancellor

of: of_private.h: Replace zero-length array with flexible-array member

2020-03-31T15:03:34+00:00

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Rob Herring

of: Rework and simplify phandle cache to use a fixed size

2019-12-24T21:17:52+00:00

The phandle cache was added to speed up of_find_node_by_phandle() by avoiding walking the whole DT to find a matching phandle. The implementation has several shortcomings: - The cache is designed to work on a linear set of phandle values. This is true for dtc generated DTs, but not for other cases such as Power. - The cache isn't enabled until of_core_init() and a typical system may see hundreds of calls to of_find_node_by_phandle() before that point. - The cache is freed and re-allocated when the number of phandles changes. - It takes a raw spinlock around a memory allocation which breaks on RT. Change the implementation to a fixed size and use hash_32() as the cache index. This greatly simplifies the implementation. It avoids the need for any re-alloc of the cache and taking a reference on nodes in the cache. We only have a single source of removing cache entries which is of_detach_node(). Using hash_32() removes any assumption on phandle values improving the hit rate for non-linear phandle values. The effect on linear values using hash_32() is about a 10% collision. The chances of thrashing on colliding values seems to be low. To compare performance, I used a RK3399 board which is a pretty typical system. I found that just measuring boot time as done previously is noisy and may be impacted by other things. Also bringing up secondary cores causes some issues with measuring, so I booted with 'nr_cpus=1'. With no caching, calls to of_find_node_by_phandle() take about 20124 us for 1248 calls. There's an additional 288 calls before time keeping is up. Using the average time per hit/miss with the cache, we can calculate these calls to take 690 us (277 hit / 11 miss) with a 128 entry cache and 13319 us with no cache or an uninitialized cache. Comparing the 3 implementations the time spent in of_find_node_by_phandle() is: no cache: 20124 us (+ 13319 us) 128 entry cache: 5134 us (+ 690 us) current cache: 819 us (+ 13319 us) We could move the allocation of the cache earlier to improve the current cache, but that just further complicates the situation as it needs to be after slab is up, so we can't do it when unflattening (which uses memblock). Reported-by: Sebastian Andrzej Siewior Cc: Michael Ellerman Cc: Segher Boessenkool Cc: Frank Rowand Acked-by: Sebastian Andrzej Siewior Reviewed-by: Frank Rowand Tested-by: Frank Rowand Signed-off-by: Rob Herring

of: Factor out #{addr,size}-cells parsing

2019-10-08T18:50:22+00:00

In some cases such as PCI host controllers, we may have a "parent bus" which is an OF leaf node, but still need to correctly parse ranges from the point of view of that bus. For that, factor out variants of the "#addr-cells" and "#size-cells" parsers which do not assume they have a device node and thus immediately traverse upwards before reading the relevant property. Signed-off-by: Robin Murphy [robh: don't make of_bus_n_{addr,size}_cells() public] Reviewed-by: Geert Uytterhoeven Tested-by: Nicolas Saenz Julienne Reviewed-by: Nicolas Saenz Julienne Signed-off-by: Rob Herring

of: Make of_dma_get_range() private

2019-10-08T18:50:22+00:00

of_dma_get_range() is only used within the DT core code, so remove the export and move the header declaration to the private header. Cc: Robin Murphy Reviewed-by: Geert Uytterhoeven Tested-by: Nicolas Saenz Julienne Reviewed-by: Nicolas Saenz Julienne Reviewed-by: Christoph Hellwig Signed-off-by: Rob Herring

of: __of_detach_node() - remove node from phandle cache

2018-12-21T18:42:36+00:00

Non-overlay dynamic devicetree node removal may leave the node in the phandle cache. Subsequent calls to of_find_node_by_phandle() will incorrectly find the stale entry. Remove the node from the cache. Add paranoia checks in of_find_node_by_phandle() as a second level of defense (do not return cached node if detached, do not add node to cache if detached). Fixes: 0b3ce78e90fc ("of: cache phandle nodes to reduce cost of of_find_node_by_phandle()") Reported-by: Michael Bringmann Cc: stable@vger.kernel.org # v4.17+ Signed-off-by: Frank Rowand Signed-off-by: Rob Herring