[U-Boot] [PATCH v2 0/7] Align U-Boot I2C DM bus ID handling with Linux

[Simon Glass]

Hi Michal,

On Thu, 31 Jan 2019 at 08:31, Michal Simek <michal.simek at 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 at ff020000
>    20: gpio at 20, offset len 1, flags 0
>    21: gpio at 21, offset len 1, flags 0
>    75: i2c-mux at 75, offset len 1, flags 0
> Bus 1:  i2c at ff020000->i2c-mux at 75->i2c at 0
> Bus 2:  i2c at ff020000->i2c-mux at 75->i2c at 1
> Bus 3:  i2c at ff020000->i2c-mux at 75->i2c at 2
> Bus 4:  i2c at ff030000  (active 4)
>    74: i2c-mux at 74, offset len 1, flags 0
>    75: i2c-mux at 75, offset len 1, flags 0
> Bus 5:  i2c at ff030000->i2c-mux at 74->i2c at 0  (active 5)
>    54: eeprom at 54, offset len 1, flags 0
> Bus 6:  i2c at ff030000->i2c-mux at 74->i2c at 1
> Bus 7:  i2c at ff030000->i2c-mux at 74->i2c at 2
> Bus 8:  i2c at ff030000->i2c-mux at 74->i2c at 3
> Bus 9:  i2c at ff030000->i2c-mux at 74->i2c at 4
> Bus 10: i2c at ff030000->i2c-mux at 75->i2c at 0
> Bus 11: i2c at ff030000->i2c-mux at 75->i2c at 1
> Bus 12: i2c at ff030000->i2c-mux at 75->i2c at 2
> Bus 13: i2c at ff030000->i2c-mux at 75->i2c at 3
> Bus 14: i2c at ff030000->i2c-mux at 75->i2c at 4
> Bus 15: i2c at ff030000->i2c-mux at 75->i2c at 5
> Bus 16: i2c at ff030000->i2c-mux at 75->i2c at 6
> Bus 17: i2c at ff030000->i2c-mux at 75->i2c at 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