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
Attachment:
signature.asc
Description: PGP signature
