On 8/4/2026 10:10 PM, Fabio Estevam wrote: > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report this > email' button > > > Hi Joseph, > > On Mon, Aug 3, 2026 at 11:42 PM Joseph Guo <[email protected]> wrote: > >> This is difference of general pcie driver in u-boot and kernel. Sorry I >> can't answer why U-boot didn't use the property. > > Please try to make the U-Boot driver understand 'linux,pci-domain = > <0>;' as Linux does. Hi Fabio,
Thanks for the suggestion to make the U-Boot driver honor `linux,pci-domain = <N>;` the way Linux does. I looked into implementing this, but I don't think it is the right fit for U-Boot, for the following reasons: 1. `linux,pci-domain` and U-Boot bus numbering solve different problems. In Linux, `linux,pci-domain` assigns a *PCI domain* (segment) number; it does not control the order in which host bridges are probed or the Linux bus numbers. U-Boot's driver model has no concept of PCI domains/segments — a PCI controller is identified only by its DM sequence number, which doubles as the root bus number. So there is no existing field to map `linux,pci-domain` onto; honoring it would mean overloading the DM sequence number with domain semantics. 2. Making U-Boot consume `linux,pci-domain` requires overriding the DM sequence number in a non-obvious way. The DM sequence number is normally assigned during the bind phase (from `/aliases`), and the only way to make a controller pick up the domain value is to overwrite `dev->seq_` later in `of_to_plat()`. This is fragile: it silently reinterprets a Linux-specific property as a U-Boot core-behavior knob, it interacts with the `pci` alias mechanism in ways that are easy to get wrong, and it changes the enumeration/listing order for *every* PCI platform, not just i.MX95. The regression surface (e.g. the `pci` command's bus-walk stopping at the first link-down root complex) is larger than the problem being solved. 3. The pci aliases are the documented [1], portable U-Boot mechanism for exactly this. U-Boot already defines pci<N> aliases as the canonical way to fix PCI controller sequence numbers (DM_UC_FLAG_SEQ_ALIAS), and other boards use them for the same purpose. Keeping the aliases in the board -u-boot.dtsi is consistent with U-Boot conventions and does not touch the upstream kernel DTS. If you main concern is keeping the U-boot DTS sync with the upstream. I can upstream the pci aliases. These aliases only influence U-Boot's DM sequence numbering; Linux ignores `pci` aliases for PCI enumeration and bus numbering, so adding them upstream is functionally a no-op for the kernel. [1] https://docs.u-boot.org/en/latest/develop/driver-model/design.html#device-sequence-numbers -- Best Regards, Joseph
