campbell+netbsd-tech-k...@mumble.net (Taylor R Campbell) writes: >I think usually it's first-come-first-serve according to the ordering >in the device tree (that is, in a pre-order traversal, which is the >same as the sequential order in the .dts file) -- not necessarily the >numbers in the device tree node names. So if there device tree lists >nodes i2c2, i2c0, i2c1, in that order, then it'll be
>/dev/iic0 -> i2c2 >/dev/iic1 -> i2c0 >/dev/iic2 -> i2c1 If you enable all interfaces (status = 'okay' in DTS) you get: % ofctl -p | grep /i2c@ 00002474: /i2c@7e205000 00002fa4: /i2c@7e804000 000030a0: /i2c@7e805000 This is also the order in the DTB: i2c@7e205000 { phandle = <0x46>; ... i2c@7e804000 { phandle = <0x4d>; ... i2c@7e805000 { phandle = <0x15>; ... In dmesg you will just see: bsciic0 at simplebus1: Broadcom Serial Controller iic0 at bsciic0: I2C bus bsciic1 at simplebus1: Broadcom Serial Controller iic1 at bsciic1: I2C bus bsciic2 at simplebus1: Broadcom Serial Controller iic2 at bsciic2: I2C bus But with drvctl you can see that the order is different. % drvctl -p bsciic0 fdt-path /soc/i2c@7e805000 % drvctl -p bsciic1 fdt-path /soc/i2c@7e205000 % drvctl -p bsciic2 fdt-path /soc/i2c@7e804000 The FDT code sorts nodes by an 'order' value, which currently is the phandle number, see the fdt_get_order() function. Another issue is that depending on the RPI model, different I2C interfaces are used by the VideoCore and attaching the driver may break functionality, so you normally do not attach all 3 interfaces but just the one that is routed to the GPIO pins.