- Dec 16, 2021
-
-
This code is required for both simplefb and simpledrm, so let's move it into the OF core instead of having it as an ad-hoc initcall in the drivers. Signed-off-by:
Hector Martin <marcan@marcan.st> Reviewed-by:
Rob Herring <robh@kernel.org> Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
- Dec 03, 2021
-
-
Since commit 04128418 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller"), a handful of interrupt controllers have stopped working correctly. This is due to the DT exposing a non-sensical interrupt-map property, and their drivers relying on the kernel ignoring this property. Since we cannot realistically fix this terrible behaviour, add a quirk for the limited set of devices that have implemented this monster, and document that this is a pretty bad practice. Fixes: 04128418 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller") Cc: Rob Herring <robh@kernel.org> Cc: John Crispin <john@phrozen.org> Cc: Biwen Li <biwen.li@nxp.com> Cc: Chris Brandt <chris.brandt@renesas.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Sander Vanheule <sander@svanheule.net> Signed-off-by:
Marc Zyngier <maz@kernel.org> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20211201114102.13446-1-maz@kernel.org Signed-off-by:
-
- Nov 12, 2021
-
-
Marc Zyngier authored
Since 04128418 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller"), the irq code favors using an interrupt-map over a interrupt-controller property if both are available, while the earlier behaviour was to ignore the interrupt-map altogether. However, we now end-up with the opposite behaviour, which is to ignore the interrupt-controller property even if the interrupt-map fails to match its input. This new behaviour breaks the AmigaOne X1000 machine, which ships with an extremely "creative" (read: broken) device tree. Fix this by allowing the interrupt-controller property to be selected when interrupt-map fails to match anything. Fixes: 04128418 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller") Reported-by:
Christian Zigotzky <chzigotzky@xenosoft.de> Reviewed-by:
-
Rob Herring authoredCommit 25b892b5 ("ARM: dts: arm: Update register-bit-led nodes 'reg' and node names") added a 'reg' property to nodes. This change has the side effect of changing how the kernel generates the device name. The assumption was a translatable 'reg' address is unique. However, in the case of the register-bit-led binding (and a few others) that is not the case. The 'mask' property must also be used in this case to make a unique device name. Fixes: 25b892b5 ("ARM: dts: arm: Update register-bit-led nodes 'reg' and node names") Reported-by:
Guenter Roeck <linux@roeck-us.net> Cc: stable@vger.kernel.org Cc: Frank Rowand <frowand.list@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211109164650.2233507-2-robh@kernel.org Signed-off-by:
-
- Nov 06, 2021
-
-
Mike Rapoport authored
Since memblock_free() operates on a physical range, make its name reflect it and rename it to memblock_phys_free(), so it will be a logical counterpart to memblock_phys_alloc(). The callers are updated with the below semantic patch: @@ expression addr; expression size; @@ - memblock_free(addr, size); + memblock_phys_free(addr, size); Link: https://lkml.kernel.org/r/20210930185031.18648-6-rppt@kernel.org Signed-off-by:Mike Rapoport <rppt@linux.ibm.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Juergen Gross <jgross@suse.com> Cc: Shahab Vahedi <Shahab.Vahedi@synopsys.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Matthew Wilcox (Oracle) authored
Not all files in the kernel should include mm.h. Migrating callers from kmalloc to kvmalloc is easier if the kvmalloc functions are in slab.h. [akpm@linux-foundation.org: move the new kvrealloc() also] [akpm@linux-foundation.org: drivers/hwmon/occ/p9_sbe.c needs slab.h] Link: https://lkml.kernel.org/r/20210622215757.3525604-1-willy@infradead.org Signed-off-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Acked-by:
Pekka Enberg <penberg@kernel.org> Cc: Christoph Lameter <cl@linux.com> Cc: David Rientjes <rientjes@google.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by:
-
- Nov 04, 2021
-
-
Marc Zyngier authored
of_irq_parse_raw() has a baked assumption that if a node has an interrupt-controller property, it cannot possibly also have an interrupt-map property (the latter being ignored). This seems to be an odd behaviour, and there is no reason why we should avoid supporting this use case. This is specially useful when a PCI root port acts as an interrupt controller for PCI endpoints, such as this: pcie0: pcie@690000000 { [...] port00: pci@0,0 { device_type = "pci"; [...] #address-cells = <3>; interrupt-controller; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &port00 0 0 0 0>, <0 0 0 2 &port00 0 0 0 1>, <0 0 0 3 &port00 0 0 0 2>, <0 0 0 4 &port00 0 0 0 3>; }; }; Handle it by detecting that we have an interrupt-map early in the parsing, and special case the situation where the phandle in the interrupt map refers to the current node (which is the interesting case here). Link: https://lore.kernel.org/r/20210929163847.2807812-3-maz@kernel.org Tested-by:Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
-
- Nov 02, 2021
-
-
Rob Herring authored
Use of the of_scan_flat_dt() function predates libfdt and is discouraged as libfdt provides a nicer set of APIs. Rework __fdt_scan_reserved_mem() to be called directly and use libfdt. Cc: Frank Rowand <frowand.list@gmail.com> Link: https://lore.kernel.org/r/20211029183615.2721777-1-robh@kernel.org/ Signed-off-by:
-
A recently implemented dtc compiler warning reports a dts problem via a build warning: drivers/of/unittest-data/tests-interrupts.dtsi:32.26-35.6: Warning (interrupt_map): /testcase-data/interrupts/intmap1: Missing '#address-cells' in interrupt-map provider The warning will be addressed by a separate patch by suppressing the warning for .dts files that include this .dtsi. This patch documents why the warning is due to a deliberately incorrect .dtsi file so that no one will fix the .dtsi file to prevent the build warning. Signed-off-by:
Frank Rowand <frank.rowand@sony.com> Link: https://lore.kernel.org/r/20211030011039.2106946-1-frowand.list@gmail.com Signed-off-by:
-
The console message text for gpio hog errors does not match what unittest expects. Fixes: f4056e70 ("of: unittest: add overlay gpio test to catch gpio hog problem") Signed-off-by:
-
Rob Herring authored
The unittest dtbs have various intentional errors which cause warnings. With the latest dtc sync to v1.6.1-19-g0a3a9d3449c8, we need to disable some new checks: node_name_vs_property_name and interrupt_map warnings. These warnings are also generated for static_base_1.dtb, so add DTC_FLAGS for it. Note that the interrupt_map warnings only appear once interrupt_provider warning is re-enabled globally. drivers/of/unittest-data/tests-interrupts.dtsi:32.26-35.6: Warning (interrupt_map): /testcase-data/interrupts/intmap1: Missing '#address-cells' in interrupt-map provider Fixes: c12632bfb611 ("scripts/dtc: Update to upstream version v1.6.1-19-g0a3a9d3449c8") Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by:
Frank Rowand <frowand.list@gmail.com> Tested-by:
-
- Oct 22, 2021
-
-
Mike Rapoport authored
Vladimir Zapolskiy reports: Commit a7259df7 ("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: a7259df7 ("memblock: make memblock_find_in_range method private") Reported-by:
Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Tested-by:
Qian Cai <quic_qiancai@quicinc.com> Signed-off-by:
-
- Oct 20, 2021
-
-
Fix following coccicheck warning: ./drivers/of/unittest.c:3091:1-23: WARNING: Function for_each_child_of_node should have of_node_put() before return Early exits from for_each_child_of_node should decrement the node reference counter. Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Link: https://lore.kernel.org/r/20211015082658.19005-1-wanjiabing@vivo.com Signed-off-by:
-
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 <nathanl@linux.ibm.com> Link: https://lore.kernel.org/r/20211014173023.2117799-1-nathanl@linux.ibm.com Signed-off-by:
-
Rob Herring authored
There are various open coded implementions parsing the CPU node 'reg' property which contains the CPU's hardware ID. Introduce a new function, of_get_cpu_hwid(), to read the hardware ID. All the callers should be DT only code, so no need for an empty function. Cc: Frank Rowand <frowand.list@gmail.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20211006164332.1981454-2-robh@kernel.org
-
- Oct 19, 2021
-
-
Wang Kefeng authored
of_amba_device_create() uses irq_of_parse_and_map() to translate a DT interrupt specification into a Linux virtual interrupt number. But it doesn't properly handle the case where the interrupt controller is not yet available, eg, when pl011 interrupt is connected to MBIGEN interrupt controller, because the mbigen initialization is too late, which will lead to no IRQ due to no IRQ domain found, log is shown below, "irq: no irq domain found for uart0 !" use of_irq_get() to return -EPROBE_DEFER as above, and in the function amba_device_try_add()/amba_device_add(), it will properly handle in such case, also return 0 in other fail cases to be consistent as before. Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Reported-by:
Ruizhe Lin <linruizhe@huawei.com> Reviewed-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
-
- Oct 15, 2021
-
-
Bjorn Andersson authored
Practically all modern Qualcomm platforms has a single reserved-memory region for SMEM. So rather than having to describe SMEM in the form of a node with a reference to a reserved-memory node, allow the SMEM device to be instantiated directly from the reserved-memory node. The current means of falling back to dereferencing the "memory-region" is kept as a fallback, if it's determined that the SMEM node is a reserved-memory node. The "qcom,smem" compatible is added to the reserved_mem_matches list, to allow the reserved-memory device to be probed. In order to retain the readability of the code, the resolution of resources is split from the actual ioremapping. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by:
-
- Oct 07, 2021
-
-
Jakub Kicinski authored
Rob suggests to move of_net.c from under drivers/of/ somewhere to the networking code. Suggested-by:
Jakub Kicinski <kuba@kernel.org> Reviewed-by:
David S. Miller <davem@davemloft.net>
-
- Oct 06, 2021
-
-
When CONFIG_OF_KOBJ was introduced in commit b56b5528 ("of: make kobject and bin_attribute support configurable") and #ifdef-ed versions of these declarations got added, the originals didn't get removed. Fixes: b56b5528 ("of: make kobject and bin_attribute support configurable") Signed-off-by:
Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20211006061943.8472-1-zev@bewilderbeest.net Signed-off-by:
-
Arnd Bergmann authored
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: 11e8f5fd ("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:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
- Oct 04, 2021
-
-
There is no device node for the empty NUMA node. However, the corresponding NUMA node ID and distance map is still valid in "numa-distance-map-v1" compatible device node. This fetches the NUMA node ID and distance map for these empty NUMA node from "numa-distance-map-v1" compatible device node. Signed-off-by:
Gavin Shan <gshan@redhat.com> Link: https://lore.kernel.org/r/20210927064119.127285-3-gshan@redhat.com Signed-off-by:
-
- Sep 17, 2021
-
-
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: f3cfd136 ("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:
-
- Sep 15, 2021
-
-
This reverts commit cf4b94c8. 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:
-
- Sep 10, 2021
-
-
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: ea718c69 ("Revert "Revert "driver core: Set fw_devlink=on by default""") Signed-off-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:
-
- Sep 03, 2021
-
-
Mike Rapoport authored
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:
Kirill A. Shutemov <kirill.shtuemov@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ACPI] Acked-by:
-
- Aug 25, 2021
-
-
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: f7e7ce93 ("of: fdt: Add generic support for handling elf core headers property") Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
-
- Aug 24, 2021
-
-
Replace the conditional compilation using "#ifdef CONFIG_BLK_DEV_INITRD" by a check for "IS_ENABLED(CONFIG_BLK_DEV_INITRD)", to increase compile coverage and to simplify the code. Signed-off-by:
-
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:
-
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:
-
- Aug 23, 2021
-
-
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:
-
Will Deacon authored
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:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
Will Deacon authored
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:
-
- Aug 18, 2021
-
-
Allows tracking dependencies between Ethernet PHYs and their consumers. Cc: Andrew Lunn <andrew@lunn.ch> Cc: netdev@vger.kernel.org Signed-off-by:
-
- Aug 17, 2021
-
-
Allows tracking dependencies between leds/backlights devices and their consumers. Signed-off-by:
-
- Aug 15, 2021
-
-
Commit 41a9ada3 ("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 aca52c39 ("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:
-
Commit e7ae8d17 ("MIPS: replace add_memory_region with memblock") removed the last architecture-specific override of early_init_dt_reserve_memory_arch(). Convert the common implementation from a weak global function to a static function. Signed-off-by:
-
- Aug 14, 2021
-
-
Allows better tracking of dependencies between devices. Signed-off-by:
-
- Aug 03, 2021
-
-
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:
-
- Jul 24, 2021
-
-
Will Deacon authored
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:
Robin Murphy <robin.murphy@arm.com> 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: fec9b625 ("of: Add plumbing for restricted DMA pool") Signed-off-by:
Konrad Rzeszutek Wilk <konrad@kernel.org>
-
- Jul 16, 2021
-
-
The FDT_PROP_* definitions make it harder to follow the code. Remove them, and use the actual string literals instead. Signed-off-by:
-
