On Wed, 2018-12-19 at 16:47 -0800, Andrey Smirnov wrote: > > > > This series initially added explicit offsets but I suggested a single > > > "controller-id" because: > > > * There are multiple bit and byte offsets > > > * Other imx8 SOCs also have 2x pcie with other bit/byte offsets > > > > > > Hiding this behind a compatible string and single "controller-id" seem > > > preferable to elaborating register maps in dt bindings. It also makes > > > upgrades simpler: if features are added which use other bits there is no > > > need to describe them in DT and deal with compatibility headaches. > > > > You already have an id for the controllers: the address. Use that if > > you don't want to put the register offsets in DT. > > > > Lucas, are you on board with this? Does address here mean the address from the controller's reg property? How do you map that address to the controller's index? A giant table of every soc so the soc type plus controller register address pair than can be looked up in the driver? I.e., on iMX8MQ the controller at 0x33800000 is controller 0 and so on for every possible SoC address combination? Not really a fan of that. The situation here is that some registers for these controllers are interleaved, right? I.e., there's one register somewhere where bit 0 means enable controller 0 and bit 1 means enable controller 1 and so on. Isn't cell-index already the standard device tree property for this kind of setup? I know cell-index was historically also (ab)used in an attempt to provide a fixed kernel device enumeration order, something now handled better by chosen node aliases.
