Use helper of_platform_default_populate() in linux/of_platform
when possible, instead of calling of_platform_populate() with
the default match table.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Grant Likely <grant.likely@linaro.org>
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NRob Herring <robh@kernel.org>

The arch code calls of_platform_populate() with default match table
when it wants to populate default bus.

This patch introduce a new of_platform_default_populate_init() and make it
arch_initcall_sync(it should be later than some iommu configration, eg,
of_iommu_init() and swiotlb_late_init in arm64), then we can finish above
job in common method.

In order to avoid the default bus being populated twice, simply checking
the flag of bus node whether has be set OF_POPULATED_BUS or not.

After that, we can safely remove the caller in arch code.

Btw, add debug print in of_platform_populate(), and use __func__ to
print function's name of of_platform_bus_create().

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Grant Likely <grant.likely@linaro.org>
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NRob Herring <robh@kernel.org>

The function is unflattening device sub-tree blob if @dad passed to
the function is valid. Currently, this functionality is used by PPC
PowerNV PCI hotplug driver only. There are possibly multiple nodes
in the first level of depth, fdt_next_node() bails immediately when
@depth becomes negative before the second device node can be probed
successfully. It leads to the device nodes except the first one won't
be unflattened successfully.

This fixes the issue by setting the initial depth (@inital_depth) to
1 when this function is called to unflatten device sub-tree blob. No
logic changes when this function is used to unflatten non-sub-tree
blob.

Cc: Rhyland Klein <rklein@nvidia.com>
Fixes: 78c44d91 ("drivers/of: Fix depth when unflattening devicetree")
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Tested-by: NRhyland Klein <rklein@nvidia.com>
Tested-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: NRob Herring <robh@kernel.org>

pageblock_order can be (at least) an unsigned int or an unsigned long
depending on the kernel config and architecture, so use max_t(unsigned
long ...) when comparing it.

fixes these warnings:

In file included from include/linux/list.h:8:0,
                 from include/linux/kobject.h:20,
                 from include/linux/of.h:21,
                 from drivers/of/of_reserved_mem.c:17:
drivers/of/of_reserved_mem.c: In function ‘__reserved_mem_alloc_size’:
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
  (void) (&_max1 == &_max2);  \
                 ^
include/linux/kernel.h:747:9: note: in definition of macro ‘max’
  typeof(y) _max2 = (y);   \
         ^
drivers/of/of_reserved_mem.c:131:48: note: in expansion of macro ‘max’
   align = max(align, (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_ord
                                                ^
include/linux/kernel.h:748:17: warning: comparison of distinct pointer types lacks a cast
  (void) (&_max1 == &_max2);  \
                 ^
include/linux/kernel.h:747:21: note: in definition of macro ‘max’
  typeof(y) _max2 = (y);   \
                     ^
drivers/of/of_reserved_mem.c:131:48: note: in expansion of macro ‘max’
   align = max(align, (phys_addr_t)PAGE_SIZE << max(MAX_ORDER - 1, pageblock_ord
                                                ^

Fixes: 1cc8e345 ("drivers: of: of_reserved_mem: fixup the alignment with CMA setup")
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NRob Herring <robh@kernel.org>

There was an alignment mismatch issue for CMA and it was fixed by
commit 1cc8e345 ("drivers: of: of_reserved_mem: fixup the alignment with CMA setup").
However the way of the commit considers not only dma-contiguous(CMA) but also
dma-coherent which has no that requirement.

This patch checks more to distinguish dma-contiguous(CMA) from dma-coherent.
Signed-off-by: NJaewon Kim <jaewon31.kim@samsung.com>
Acked-by: NJason Liu <r64343@freescale.com>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
[robh: remove erroneous opening bracket]
Signed-off-by: NRob Herring <robh@kernel.org>

The kernel-doc for the of_irq_get[_byname]()  is clearly inadequate in
describing the return values -- of_irq_get_byname() is documented better
than of_irq_get() but it  still doesn't mention that 0 is returned iff
irq_create_of_mapping() fails (it doesn't return an error code in this
case). Document all possible return value variants, making the writing
of the word "IRQ" consistent, while at it...

Fixes: 9ec36caf ("of/irq: do irq resolution in platform_get_irq")
Fixes: ad69674e ("of/irq: do irq resolution in platform_get_irq_byname()")
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
CC: stable@vger.kernel.org
Signed-off-by: NRob Herring <robh@kernel.org>

The OF_UNITTEST Kconfig symbol is bool so this unittest can only be
built-in and not build as a module. Also, nothing defined in this
header file used so is not necessary to include it.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NRob Herring <robh@kernel.org>

Function populate_node() is used to unflatten FDT blob to device
tree. It supports maximal 64 level of device nodes. There is one
array @fpsizes[64] tracking the full name length of last unflattened
device node in the corresponding level (index of element in the
array - 1). Build warning is seen with CONFIG_FRAME_WARN=1024 like
below on ARM64 as Geert reported. The issue can be reproduced on
PPC64 as well.

  $ make drivers/of/fdt.o
  drivers/of/fdt.c:443:1: warning: the frame size of 1136 bytes is \
  larger than 1024 bytes [-Wframe-larger-than=]

This changes the data type of @fpsizes[i] from "unsigned long" to
"unsigned int" to avoid the build warning. The return value type
of populate_node() and its @fpsize argument is adjusted accordingly.
With this applied, 256 bytes saved from the stack frame on ARM64 and
PPC64 platforms and the above warning isn't seen.

Fixes: 50800082 ("drivers/of: Avoid recursively calling unflatten_dt_node()")
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NRob Herring <robh@kernel.org>

When the implementation for unflatten_dt_node() changed from being
recursive to being non-recursive, it had a side effect of increasing the
depth passed to fdt_next_node() by 1. This is fine most of the time, but
it seems that when the end of the dtb is being parsed, it will cause the
FDT_END condition in fdt_next_node() to return a different value
(returning nextoffset instead of -FDT_ERR_NOTFOUND). This ends up passing
an FDT_ERR_TRUNCATED error back to the unflatten_dt_node() which then
sees that and complains "Error -8 processing FDT" causing boot to fail.

This patch simply avoids incrementing depth and uses modified accesses
for local array indices so that the depth is the same as it was before
the change as far as fdt_next_node() is concerned.

This problem was discovered trying to boot Tegra210-Smaug platforms.

Fixes: 50800082 ("drivers/of: Avoid recursively calling unflatten_dt_node()")
Signed-off-by: NRhyland Klein <rklein@nvidia.com>
[robh: squashed in KASAN fix from Rhyland]
Signed-off-by: NRob Herring <robh@kernel.org>

When reverting an update property changeset entry that created a
property the reverse operation is a remove property and not an update.
Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: NRob Herring <robh@kernel.org>

This exports of_detach_node() for PowerPC PowerNV PCI hotplug
driver. No functional changes introduced.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NRob Herring <robh@kernel.org>

This returns the allocate memory chunk, storing the unflattened device
tree, from of_fdt_unflatten_tree() so that memory chunk can be released
on demand in PowerNV PCI hotplug driver.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRob Herring <robh@kernel.org>

This adds one more argument to of_fdt_unflatten_tree() to specify
the parent node of the FDT blob that is going to be unflattened.
In the result, the function can be used to unflatten FDT blob that
represents device sub-tree in PowerNV PCI hotplug driver.

Cc: Jyri Sarha <jsarha@ti.com>
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: NRob Herring <robh@kernel.org>
Acked-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NRob Herring <robh@kernel.org>

This renames unflatten_dt_node() to unflatten_dt_nodes() as it
populates multiple device nodes from FDT blob. No logical changes
introduced.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRob Herring <robh@kernel.org>

In current implementation, unflatten_dt_node() is called recursively
to unflatten device nodes in FDT blob. It's stress to limited stack
capacity, especially to adopt the function to unflatten device sub-tree
that possibly has multiple root nodes. In that case, we runs out of
stack and the system can't boot up successfully.

In order to reuse the function to unflatten device sub-tree, this avoids
calling the function recursively, meaning the device nodes are unflattened
in one call on unflatten_dt_node(): two arrays are introduced to track the
parent path size and the device node of current level of depth, which will
be used by the device node on next level of depth to be unflattened. All
device nodes in more than 64 level of depth are dropped and hopefully,
the system can boot up successfully with the partial device-tree.

Also, the parameter "poffset" and "fpsize" are unused and dropped and the
parameter "dryrun" is figured out from "mem == NULL". Besides, the return
value of the function is changed to indicate the size of memory consumed by
the unflatten device tree or error code.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRob Herring <robh@kernel.org>

The function unflatten_dt_node() is called recursively to unflatten
device nodes and properties in the FDT blob. It looks complicated
and hard to be understood.

This splits the function into 3 functions: populate_properties(),
populate_node() and unflatten_dt_node(). populate_properties(),
which is called by populate_node(), creates properties for the
indicated device node. The later one creates the device nodes
from FDT blob. populate_node() gets the offset in FDT blob for
next device nodes and then calls populate_node(). No logical
changes introduced.
Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRob Herring <robh@kernel.org>

No functional changes in this patch.

PCI I/O space mapping code does not depend on OF; therefore it can be moved
to PCI core code.  This way we will be able to use it, e.g., in ACPI PCI
code.
Suggested-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Liviu Dudau <Liviu.Dudau@arm.com>

The validity of the property input argument to of_remove_property() is
never checked within the function and thus it is possible to pass a null
value. It happens that this will be picked up in __of_remove_property()
as no matching property of the device node will be found and thus an
error will be returned, however once again there is no explicit check
for a null value. By the time this is detected 2 locks have already been
acquired which is completely unnecessary if the property to remove is
null.

Add an explicit check in the function of_remove_property() for a null
property value and return -ENODEV in this case, this is consistent with
what the previous return value would have been when the null value was
not detected and passed to __of_remove_property().

By moving an explicit check for the property paramenter into the
of_remove_property() function, this will remove the need to perform this
check in calling code before invocation of the of_remove_property()
function.
Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

As a set of driver-provided callbacks and static data, there is no
compelling reason for struct iommu_ops to be mutable in core code, so
enforce const-ness throughout.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

Now that all drivers go through nand_set_flash_node() to parse the generic
NAND properties, we can move all of_get_nand_xxx() helpers in to
nand_base.c, make them static and remove of_mtd.c and of_mtd.h.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Add a check whether the 'struct device_node' pointer passed to
of_mdiobus_register() is an available (aka enabled) node in the Device
Tree.

Rationale for doing this are cases where an Ethernet MAC provides a MDIO
bus controller and node, and an additional Ethernet MAC might be
connecting its PHY/switches to that first MDIO bus controller, while
still embedding one internally which is therefore marked as "disabled".

Instead of sprinkling checks like these in callers of
of_mdiobus_register(), do this in a central location.
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Now that get_phy_device() no longer returns NULL on error, we don't need
to check for it...
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This function increments refcount.  This is worth noting.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NFrank Rowand <frank.rowand@am.sony.com>
Signed-off-by: NRob Herring <robh@kernel.org>

Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select op to be in terms of the i2c mux core instead
of the child adapter.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This helper function can be used to copy the arguments of a
phandle to an array.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NRob Herring <robh@kernel.org>

With this macro any user can easily iterate over a list of
phandles. The patch also converts __of_parse_phandle_with_args()
to make use of the macro.

The of_count_phandle_with_args() function is not converted,
because the macro hides the return value of of_phandle_iterator_init(),
which is needed in there.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NRob Herring <robh@kernel.org>

The index = -1 case in __of_parse_phandle_with_args() is
used to just return the number of phandles. That special
case needs extra handling, so move it to the place where it
is needed: of_count_phandle_with_args().

This allows to further simplify __of_parse_phandle_with_args()
later on.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NRob Herring <robh@kernel.org>

Move the code to walk over the phandles out of the loop in
__of_parse_phandle_with_args() to a separate function that
just works with the iterator handle: of_phandle_iterator_next().
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NRob Herring <robh@kernel.org>

This struct carrys all necessary information to iterate over
a list of phandles and extract the arguments. Add an
init-function for the iterator and make use of it in
__of_parse_phandle_with_args().
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NRob Herring <robh@kernel.org>

On arm CONFIG_CMDLINE_EXTEND does not append build-in
cmdline in kernel to U-boot parameters. Fix it here.
Theoretically this patch should repair kdump work where
it adds elfcorehdr= and memmap additional parameters
to second kernel.
Signed-off-by: NMax Uvarov <muvarov@gmail.com>
Signed-off-by: NRob Herring <robh@kernel.org>

NAND subsystem is being slightly reworked to store ECC details in
separated fields. In future we'll want to add support for more DT
properties as specifying every possible setup with a single
"nand-ecc-mode" is a pretty bad idea.
To allow this let's add a helper that will support something like
"nand-ecc-algo" in future. Right now we use it for keeping backward
compatibility.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The results of of_mdiobus_register_{device|phy}() are never checked, so we
can make  both these functions *void*...
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add device tree parsing for NUMA topology using device
"numa-node-id" property in distance-map and cpu nodes.

This is a complete rewrite of a previous patch by:
   Ganapatrao Kulkarni<gkulkarni@caviumnetworks.com>
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

We currently try to match of_dev_auxdata based on compatible,
IO address, and device name. But in some cases we have multiple
instances of drivers that can use the same auxdata.

Let's add an additional secondary lookup for generic compatible
match for auxdata if no device specific match is found. This does
not change the existing matching, and still allows adding device
specific auxdata.

This simplifies things as specifying the IO address and device
name is prone errors as it requires maintaining an in kernel
database for each SoC.

To specify a generic match, all that is needed is to add a
OF_DEV_AUXDATA entry with no device instance specified:

OF_DEV_AUXDATA("pinctrl-single", 0, NULL, &pcs_pdata),

As the auxdata is already initialized only for the booted SoC,
there's not much of a chance of getting things wrong.

Let's also fix two checkpatch warnings while at it to add a
space before parenthesis in the for loop, and remove a comparison
to NULL by using !auxdata->compatible.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

PTR_ERR_OR_ZERO() is open coded in of_phy_register_fixed_link(), so just
call it directly...
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

IS_ERR_OR_NULL() is open coded in of_mdiobus_register_phy(), so just call
it directly...
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

mdio_device_create() never returns NULL, thus checking for it in
of_mdiobus_register_device() is pointless...
Suggested-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The of_property_{read,count,match}_string* family of functions never
modify the struct device_node pointer that is passed in, so there is no
reason for it to be non-const. Equivalent functions for all other types
already take a 'const struct device_node *np'.
Signed-off-by: NDavid Rivshin <drivshin@allworx.com>
Signed-off-by: NRob Herring <robh@kernel.org>

of_overlay_destroy() can return `-ENODEV' error code once it
failed to find the requested overlay in `ov_idr'. However,
of_unittest_destroy_tracked_overlays() does not handle this
error code correctly and continues to call of_overlay_destroy()
on the 'missing' overlay over and over again. This results in
a printk flood

[..]
[   33.497583] of_overlay_destroy: Could not find overlay #6
[   33.497583] of_overlay_destroy: Could not find overlay #6
[   33.497584] ### dt-test ### of_unittest_destroy_tracked_overlays: overlay destroy failed for #6
[   33.497584] ### dt-test ### of_unittest_destroy_tracked_overlays: overlay destroy failed for #6
[   33.497586] of_overlay_destroy: Could not find overlay #6
[   33.497586] of_overlay_destroy: Could not find overlay #6
[   33.497587] ### dt-test ### of_unittest_destroy_tracked_overlays: overlay destroy failed for #6
[   33.497587] ### dt-test ### of_unittest_destroy_tracked_overlays: overlay destroy failed for #6
[..]

which is not really good due to printk design, and can lead to soft
lockups, hard lockups, etc. (depending on the context console_unlock()
is being called from). The problem has bee observed in real life
and reported by Ying Huang.

This patch does not address the root cause of missing overlay in
`ov_idr', it fixes the endless loop only.
Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Nkernel test robot <ying.huang@linux.intel.com>
Link: lkml.kernel.org/r/87fuwk1c0o.fsf@yhuang-dev.intel.com
Signed-off-by: NRob Herring <robh@kernel.org>

early_init_dt_alloc_reserved_memory_arch passes end as 0 to
__memblock_alloc_base, when limits are not specified. But
__memblock_alloc_base takes end value of 0 as MEMBLOCK_ALLOC_ACCESSIBLE
and limits the end to memblock.current_limit. This results in regions
never being placed in HIGHMEM area, for e.g. CMA.
Let __memblock_alloc_base allocate from anywhere in memory if limits are
not specified.
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NVinayak Menon <vinmenon@codeaurora.org>
Cc: stable@vger.kernel.org
Signed-off-by: NRob Herring <robh@kernel.org>