Hi Michal, On Thu, 31 Jan 2019 at 08:31, Michal Simek <michal.si...@xilinx.com> wrote: > > U-Boot with I2C_DM enabled is not capable to list i2c busses connected > to i2c mux. For getting this work there is a need to find out highest > alias ID and use this uniq number for new buses connected to I2C mux. > This series is making this happen. > > There is only one missing piece which is that also i2c controllers which > are not listed in DT are not using this feature. > > Removing setting up aliases from i2c mux code and unifying it in the > same code ensures that numbering schema is proper if no alias is > specified. > > ZynqMP> i2c bus > Bus 0: i2c@ff020000 > 20: gpio@20, offset len 1, flags 0 > 21: gpio@21, offset len 1, flags 0 > 75: i2c-mux@75, offset len 1, flags 0 > Bus 1: i2c@ff020000->i2c-mux@75->i2c@0 > Bus 2: i2c@ff020000->i2c-mux@75->i2c@1 > Bus 3: i2c@ff020000->i2c-mux@75->i2c@2 > Bus 4: i2c@ff030000 (active 4) > 74: i2c-mux@74, offset len 1, flags 0 > 75: i2c-mux@75, offset len 1, flags 0 > Bus 5: i2c@ff030000->i2c-mux@74->i2c@0 (active 5) > 54: eeprom@54, offset len 1, flags 0 > Bus 6: i2c@ff030000->i2c-mux@74->i2c@1 > Bus 7: i2c@ff030000->i2c-mux@74->i2c@2 > Bus 8: i2c@ff030000->i2c-mux@74->i2c@3 > Bus 9: i2c@ff030000->i2c-mux@74->i2c@4 > Bus 10: i2c@ff030000->i2c-mux@75->i2c@0 > Bus 11: i2c@ff030000->i2c-mux@75->i2c@1 > Bus 12: i2c@ff030000->i2c-mux@75->i2c@2 > Bus 13: i2c@ff030000->i2c-mux@75->i2c@3 > Bus 14: i2c@ff030000->i2c-mux@75->i2c@4 > Bus 15: i2c@ff030000->i2c-mux@75->i2c@5 > Bus 16: i2c@ff030000->i2c-mux@75->i2c@6 > Bus 17: i2c@ff030000->i2c-mux@75->i2c@7 > > Thanks, > Michal > > Changes in v2: > - Update kernel-doc binding > - Return -1 in case of error. -1 means that the next free alias is 0. > - New patch > - New patch > - Use dev_read_alias_highest_id() > - Use uclass private data > - Use private uclass data > - Fix headers > - Change patch description to focus only on bus name
I don't have strong objections to this series, but I'd still like to try a bit harder on the existing req_seq/seq stuff. I don't think we necessarily need to set the 'seq' before probe, although I suppose we could. But is there anything to stop us moving some of the logic which sets seq to setting req_seq? We could check the aliases and then set req_seq during bind(), perhaps? This would be better for code size since it would help all subsystems. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot