Hi Luca,

> > This looks quite inefficient, especially if the beginning of the range
> > is populated with devices. Furthermore, I think there's a high risk of
> > false negatives, as acquiring a free address and reprogramming the
> > client to make use of it are separate operations.
> 
> Right. Applying the alias could raise other errors, thus one would need
> i2c_new_alias_device() to keep the alias locked until programming it has
> either failed or has been successfully programmed.

Please see my reply to Laurent, I don't think it is racy. But please
elaborate if you think I am wrong.

> > What happened to the idea of reporting busy address ranges in the
> > firmware (DT, ACPI, ...) ?
> 
> Indeed that's how I remember it as well, and I'm a bit suspicious about
> sending out probe messages that might have side effects (even if the
> false negative issue mentioned by Laurent were solved). You know, I've
> been taught to "expect the worse" :) so I'd like to better understand
> what are the strong reasons in favor of probing, as well as the
> potential side effects.

As I said to Laurent, too, I think the risk that a bus is not fully
described is higher than a device which does not respond to a read_byte.
In both cases, we would wrongly use an address in use.

Also, all the best for you in 2020!

   Wolfram