tjh.dev
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the reStructuredText markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
fork
Configure Feed
Select the types of activity you want to include in your feed.
1442234
3
927
Clone this repository
https://tangled.org/tjh.dev/kernel
https://tangled.org/did:plc:65gha4t3avpfpzmvpbwovss7/kernel
git@gordian.tjh.dev:tjh.dev/kernel
git@gordian.tjh.dev:did:plc:65gha4t3avpfpzmvpbwovss7/kernel
For self-hosted knots, clone URLs may differ based on your setup.
Download tar.gz
The current code uses some 'goto put;' to cancel the parsing operation
and can lead to a return code value of 0 even on error cases.
Indeed, some goto calls are done from a loop without setting the ret
value explicitly before the goto call and so the ret value can be set to
0 due to operation done in previous loop iteration. For instance match
can be set to 0 in the previous loop iteration (leading to a new
iteration) but ret can also be set to 0 it the of_property_read_u32()
call succeed. In that case if no match are found or if an error is
detected the new iteration, the return value can be wrongly 0.
Avoid those cases setting the ret value explicitly before the goto
calls.
Fixes: bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through a nexus node")
Cc: stable@vger.kernel.org
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://lore.kernel.org/r/20241202165819.158681-1-herve.codina@bootlin.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The example erroneously has "compress" property rather than the
documented "compression" property.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20241113225632.1783241-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
On systems where ACPI is enabled or when a device-tree is not passed to
the kernel by the bootloader, a device-tree root empty node is created.
This device-tree root empty node does not have the #address-cells and
the #size-cells properties
This leads to the use of the default address cells and size cells values
which are defined in the code to 1 for the address cells value and 1 for
the size cells value.
According to the devicetree specification and the OpenFirmware standard
(IEEE 1275-1994) the default value for #address-cells should be 2.
Also, according to the devicetree specification, the #address-cells and
the #size-cells are required properties in the root node.
The device tree compiler already uses 2 as default value for address
cells and 1 for size cells. The powerpc PROM code also uses 2 as default
value for address cells and 1 for size cells. Modern implementation
should have the #address-cells and the #size-cells properties set and
should not rely on default values.
On x86, this root empty node is used and the code default values are
used.
In preparation of the support for device-tree overlay on PCI devices
feature on x86 (i.e. the creation of the PCI root bus device-tree node),
the default value for #address-cells needs to be updated. Indeed, on
x86_64, addresses are on 64bits and the upper part of an address is
needed for correct address translations. On x86_32 having the default
value updated does not lead to issues while the upper part of a 64-bit
value is zero.
Changing the default value for all architectures may break device-tree
compatibility. Indeed, existing dts file without the #address-cells
property set in the root node will not be compatible with this
modification.
Instead of updating default values, add both required #address-cells
and #size-cells properties in the device-tree empty node.
Use 2 for both properties value in order to fully support 64-bit
addresses and sizes on systems using this empty root node.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://lore.kernel.org/r/20241202131522.142268-6-herve.codina@bootlin.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The type definition of "fsl,liodn" is defined as uint32 in
crypto/fsl,sec-v4.0.yaml and uint32-array in soc/fsl/fsl,bman.yaml,
soc/fsl/fsl,qman-portal.yaml, and soc/fsl/fsl,qman.yaml. Unify the type to
be uint32-array and constraint the single entry cases.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20241113225614.1782862-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
A missing or empty dma-ranges in a DT node implies a 1:1 mapping for dma
translations. In this specific case, the current behaviour is to zero out
the entire specifier so that the translation could be carried on as an
offset from zero. This includes address specifier that has flags (e.g.
PCI ranges).
Once the flags portion has been zeroed, the translation chain is broken
since the mapping functions will check the upcoming address specifier
against mismatching flags, always failing the 1:1 mapping and its entire
purpose of always succeeding.
Set to zero only the address portion while passing the flags through.
Fixes: dbbdee94734b ("of/address: Merge all of the bus translation code")
Cc: stable@vger.kernel.org
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
Tested-by: Herve Codina <herve.codina@bootlin.com>
Link: https://lore.kernel.org/r/e51ae57874e58a9b349c35e2e877425ebc075d7a.1732441813.git.andrea.porta@suse.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Intermediate DT PCI nodes dynamically generated by enabling
CONFIG_PCI_DYNAMIC_OF_NODES have empty dma-ranges property. PCI address
specifiers have 3 cells and when dma-ranges is missing or empty,
of_translate_one() is currently dropping the flag portion of PCI addresses
which are subnodes of the aforementioned ones, failing the translation.
Add new tests covering this case.
With this test, we get 1 new failure which is fixed in subsequent
commit:
FAIL of_unittest_pci_empty_dma_ranges():1245 for_each_of_pci_range wrong CPU addr (ffffffffffffffff) on node /testcase-data/address-tests2/pcie@d1070000/pci@0,0/dev@0,0/local-bus@0
Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
Link: https://lore.kernel.org/r/08f8fee4fdc0379240fda2f4a0e6f11ebf9647a8.1732441813.git.andrea.porta@suse.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
commit 7f00be96f125 ("of: property: Add device link support for
interrupt-parent, dmas and -gpio(s)") started adding device links for
the interrupt-parent property. commit 4104ca776ba3 ("of: property: Add
fw_devlink support for interrupts") and commit f265f06af194 ("of:
property: Fix fw_devlink handling of interrupts/interrupts-extended")
later added full support for parsing the interrupts and
interrupts-extended properties, which includes looking up the node of
the parent domain. This made the handler for the interrupt-parent
property redundant.
In fact, creating device links based solely on interrupt-parent is
problematic, because it can create spurious cycles. A node may have
this property without itself being an interrupt controller or consumer.
For example, this property is often present in the root node or a /soc
bus node to set the default interrupt parent for child nodes. However,
it is incorrect for the bus to depend on the interrupt controller, as
some of the bus's children may not be interrupt consumers at all or may
have a different interrupt parent.
Resolving these spurious dependency cycles can cause an incorrect probe
order for interrupt controller drivers. This was observed on a RISC-V
system with both an APLIC and IMSIC under /soc, where interrupt-parent
in /soc points to the APLIC, and the APLIC msi-parent points to the
IMSIC. fw_devlink found three dependency cycles and attempted to probe
the APLIC before the IMSIC. After applying this patch, there were no
dependency cycles and the probe order was correct.
Acked-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Fixes: 4104ca776ba3 ("of: property: Add fw_devlink support for interrupts")
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
Link: https://lore.kernel.org/r/20241120233124.3649382-1-samuel.holland@sifive.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Pull-in kunit kconfig fix
Document compatible for PDC interrupt controller on SAR2130P platform.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20241017-sar2130p-pdc-v1-1-cf9ccd9c37da@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Some configurations want to enable CONFIG_KUNIT without enabling
CONFIG_OF_OVERLAY. The kunit overlay code already skips if
CONFIG_OF_OVERLAY isn't enabled, so this select here isn't really doing
anything besides making it easier to run the tests without them
skipping. Remove the select and move the config setting to the
drivers/of/.kunitconfig file so that the overlay tests can be run with
or without CONFIG_OF_OVERLAY set to test either behavior.
Fixes: 5c9dd72d8385 ("of: Add a KUnit test for overlays and test managed APIs")
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20241016212016.887552-1-sboyd@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
With warnings added for deprecated #address-cells/#size-cells handling,
the DT address handling code causes warnings when used on nodes with no
address. This happens frequently with calls to of_platform_populate() as
it is perfectly acceptable to have devices without a 'reg' property. The
desired behavior is to just silently return an error when retrieving an
address.
The warnings can be avoided by checking for "#address-cells" presence
first and checking for an address property before fetching
"#address-cells" and "#size-cells".
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reported-by: Steven Price <steven.price@arm.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20241108193547.2647986-2-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
A root node is required to apply DT overlays. A root node is usually
present after commit 7b937cc243e5 ("of: Create of_root if no dtb
provided by firmware"), except for on arm64 systems booted with ACPI
tables. In that case, the root node is intentionally not populated
because it would "allow DT devices to be instantiated atop an ACPI base
system"[1].
Introduce an OF function that skips the kunit test if the root node
isn't populated. Limit the test to when both CONFIG_ARM64 and
CONFIG_ACPI are set, because otherwise the lack of a root node is a bug.
Make the function private and take a kunit test parameter so that it
can't be abused to test for the presence of the root node in non-test
code.
Use this function to skip tests that require the root node. Currently
that's the DT tests and any tests that apply overlays.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Closes: https://lore.kernel.org/r/6cd337fb-38f0-41cb-b942-5844b84433db@roeck-us.net
Link: https://lore.kernel.org/r/Zd4dQpHO7em1ji67@FVFF77S0Q05N.cambridge.arm.com [1]
Fixes: 893ecc6d2d61 ("of: Add KUnit test to confirm DTB is loaded")
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20241009204133.1169931-1-sboyd@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
While OpenFirmware originally allowed walking parent nodes and default
root values for #address-cells and #size-cells, FDT has long required
explicit values. It's been a warning in dtc for the root node since the
beginning (2005) and for any parent node since 2007. Of course, not all
FDT uses dtc, but that should be the majority by far. The various
extracted OF devicetrees I have dating back to the 1990s (various
PowerMac, OLPC, PASemi Nemo) all have explicit root node properties. The
warning is disabled for Sparc as there are known systems relying on
default root node values.
Link: https://lore.kernel.org/r/20241106171028.3830266-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Got following report when doing overlay_test:
OF: ERROR: memory leak, expected refcount 1 instead of 2,
of_node_get()/of_node_put() unbalanced - destroy cset entry:
attach overlay node /kunit-test
OF: ERROR: memory leak before free overlay changeset, /kunit-test
In of_overlay_apply_kunit_cleanup(), the "np" should be associated with
fake instead of test to call of_node_put(), so the node is put before
the overlay is removed.
It also fix the following memory leaks:
unreferenced object 0xffffff80c7d22800 (size 256):
comm "kunit_try_catch", pid 236, jiffies 4294894764
hex dump (first 32 bytes):
d0 26 d4 c2 80 ff ff ff 00 00 00 00 00 00 00 00 .&..............
60 19 75 c1 80 ff ff ff 00 00 00 00 00 00 00 00 `.u.............
backtrace (crc ee0a471c):
[<0000000058ea1340>] kmemleak_alloc+0x34/0x40
[<00000000c538ac7e>] __kmalloc_cache_noprof+0x26c/0x2f4
[<00000000119f34f3>] __of_node_dup+0x4c/0x328
[<00000000b212ca39>] build_changeset_next_level+0x2cc/0x4c0
[<00000000eb208e87>] of_overlay_fdt_apply+0x930/0x1334
[<000000005bdc53a3>] of_overlay_fdt_apply_kunit+0x54/0x10c
[<00000000143acd5d>] of_overlay_apply_kunit_cleanup+0x12c/0x524
[<00000000a813abc8>] kunit_try_run_case+0x13c/0x3ac
[<00000000d77ab00c>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<000000000b296be1>] kthread+0x2e8/0x374
[<0000000007bd1c51>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80c1751960 (size 16):
comm "kunit_try_catch", pid 236, jiffies 4294894764
hex dump (first 16 bytes):
6b 75 6e 69 74 2d 74 65 73 74 00 c1 80 ff ff ff kunit-test......
backtrace (crc 18196259):
[<0000000058ea1340>] kmemleak_alloc+0x34/0x40
[<0000000071006e2c>] __kmalloc_node_track_caller_noprof+0x300/0x3e0
[<00000000b16ac6cb>] kstrdup+0x48/0x84
[<0000000050e3373b>] __of_node_dup+0x60/0x328
[<00000000b212ca39>] build_changeset_next_level+0x2cc/0x4c0
[<00000000eb208e87>] of_overlay_fdt_apply+0x930/0x1334
[<000000005bdc53a3>] of_overlay_fdt_apply_kunit+0x54/0x10c
[<00000000143acd5d>] of_overlay_apply_kunit_cleanup+0x12c/0x524
[<00000000a813abc8>] kunit_try_run_case+0x13c/0x3ac
[<00000000d77ab00c>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<000000000b296be1>] kthread+0x2e8/0x374
[<0000000007bd1c51>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80c2e96e00 (size 192):
comm "kunit_try_catch", pid 236, jiffies 4294894764
hex dump (first 32 bytes):
80 19 75 c1 80 ff ff ff 0b 00 00 00 00 00 00 00 ..u.............
a0 19 75 c1 80 ff ff ff 00 6f e9 c2 80 ff ff ff ..u......o......
backtrace (crc 1924cba4):
[<0000000058ea1340>] kmemleak_alloc+0x34/0x40
[<00000000c538ac7e>] __kmalloc_cache_noprof+0x26c/0x2f4
[<000000009fdd35ad>] __of_prop_dup+0x7c/0x2ec
[<00000000aa4e0111>] add_changeset_property+0x548/0x9e0
[<000000004777e25b>] build_changeset_next_level+0xd4/0x4c0
[<00000000a9c93f8a>] build_changeset_next_level+0x3a8/0x4c0
[<00000000eb208e87>] of_overlay_fdt_apply+0x930/0x1334
[<000000005bdc53a3>] of_overlay_fdt_apply_kunit+0x54/0x10c
[<00000000143acd5d>] of_overlay_apply_kunit_cleanup+0x12c/0x524
[<00000000a813abc8>] kunit_try_run_case+0x13c/0x3ac
[<00000000d77ab00c>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<000000000b296be1>] kthread+0x2e8/0x374
[<0000000007bd1c51>] ret_from_fork+0x10/0x20
unreferenced object 0xffffff80c1751980 (size 16):
comm "kunit_try_catch", pid 236, jiffies 4294894764
hex dump (first 16 bytes):
63 6f 6d 70 61 74 69 62 6c 65 00 c1 80 ff ff ff compatible......
backtrace (crc 42df3c87):
[<0000000058ea1340>] kmemleak_alloc+0x34/0x40
[<0000000071006e2c>] __kmalloc_node_track_caller_noprof+0x300/0x3e0
[<00000000b16ac6cb>] kstrdup+0x48/0x84
[<00000000a8888fd8>] __of_prop_dup+0xb0/0x2ec
[<00000000aa4e0111>] add_changeset_property+0x548/0x9e0
[<000000004777e25b>] build_changeset_next_level+0xd4/0x4c0
[<00000000a9c93f8a>] build_changeset_next_level+0x3a8/0x4c0
[<00000000eb208e87>] of_overlay_fdt_apply+0x930/0x1334
[<000000005bdc53a3>] of_overlay_fdt_apply_kunit+0x54/0x10c
[<00000000143acd5d>] of_overlay_apply_kunit_cleanup+0x12c/0x524
[<00000000a813abc8>] kunit_try_run_case+0x13c/0x3ac
[<00000000d77ab00c>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<000000000b296be1>] kthread+0x2e8/0x374
unreferenced object 0xffffff80c2e96f00 (size 192):
comm "kunit_try_catch", pid 236, jiffies 4294894764
hex dump (first 32 bytes):
40 f7 bb c6 80 ff ff ff 0b 00 00 00 00 00 00 00 @...............
c0 19 75 c1 80 ff ff ff 00 00 00 00 00 00 00 00 ..u.............
backtrace (crc f2f57ea7):
[<0000000058ea1340>] kmemleak_alloc+0x34/0x40
[<00000000c538ac7e>] __kmalloc_cache_noprof+0x26c/0x2f4
[<000000009fdd35ad>] __of_prop_dup+0x7c/0x2ec
[<00000000aa4e0111>] add_changeset_property+0x548/0x9e0
[<000000004777e25b>] build_changeset_next_level+0xd4/0x4c0
[<00000000a9c93f8a>] build_changeset_next_level+0x3a8/0x4c0
[<00000000eb208e87>] of_overlay_fdt_apply+0x930/0x1334
[<000000005bdc53a3>] of_overlay_fdt_apply_kunit+0x54/0x10c
[<00000000143acd5d>] of_overlay_apply_kunit_cleanup+0x12c/0x524
[<00000000a813abc8>] kunit_try_run_case+0x13c/0x3ac
[<00000000d77ab00c>] kunit_generic_run_threadfn_adapter+0x80/0xec
[<000000000b296be1>] kthread+0x2e8/0x374
[<0000000007bd1c51>] ret_from_fork+0x10/0x20
......
How to reproduce:
CONFIG_OF_OVERLAY_KUNIT_TEST=y, CONFIG_DEBUG_KMEMLEAK=y
and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, launch the kernel.
Fixes: 5c9dd72d8385 ("of: Add a KUnit test for overlays and test managed APIs")
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20241010034416.2324196-1-ruanjinjie@huawei.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
FDT systems should never be relying on default cell sizes. It's been a
warning in dtc since 2007. The behavior here doesn't even match the
unflattened code which will walk the parent nodes looking for the cell
size properties (also deprecated). Furthermore, the FDT address
translation code is only used in one spot by SH and for earlycon which
was added 2014 and certainly isn't used on Powerpc systems.
Returning -1 values will result in an error message.
Link: https://lore.kernel.org/r/20241106170808.3827790-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
README