I have a requirement to send a reset signal to a switch using GPIO before the ethernet controller is configured (i.e. before ethernet controller driver and device binding). I have added the reset logic in the GPIO controller driver and gpio controller device node entry in the device tree. It is working fine.
I have converted final dtb file to dts and checked the device nodes order, the ethernet controller device node is ahead of gpio controller device node. But during boot time GPIO controller driver binding is happening before ethernet controller driver binding, so it is working fine. I have restarted multiple times and observed that GPIO controller is coming before ethernet controller always.
Is there any place where the device tree device nodes binding order is updated. My concern is that if ethernet controller driver binding happens before GPIO controller then the functionality will not work.
How the device tree device nodes binding order is decided?
Instead of "binding", you presumably mean driver initialization.
Linux kernel Documentation/driver-api/driver-model/binding.rst defines driver binding as "the process of associating a device with a device driver that can control it."
(The Linux kernel tends to combine or conflate the driver initialization with device probing & binding, especially at boot time.)
Your gpio controller driver probably declares its initialization routine using the subsys_initcall() macro.
Whereas your Ethernet (MAC?) driver probably declares its initialization routine using the module_init() macro.
See What is the difference between module_init and subsys_initcall while initializing the driver?
Bottom line: the driver using subsys_initcall() is meant to always be initialized before any and all drivers using module_init().
No, you're making an assumption that has no foundation.
Your unstated premise that the order of nodes in the Device Tree somehow determines the initialization order of device drivers and/or device probing/binding is false.
See The order in which the device-tree text file is written, does it matter?
"Binding order" is essentially determined by the order that driver initialization routines are executed.
The order of nodes in the flattened Device Tree determines nothing.
The Linux kernel avoids relying on the Device Tree for any ordering because only a few processor architectures use the DT. Those arches only use the DT to provide system/device configuration.
See Documentation/devicetree/usage-model.rst.
On a running system, inspect /proc/device-tree/, and find the subdirectory for your peripheral bus. Whatever sequence the nodes were ordered in the source DT is not preserved here.
Within an initcall level, the order that driver routines are executed is determined at kernel build time.
This is documented in the kernel source in /include/linux/init.h:
If your drivers do happen to use the same init level, then for a solution see
What is the Linux built-in driver load order?
and
Serializing the driver's init call order, which were registered at the same init level