Hi Wolfram, On 02/01/20 22:13, Wolfram Sang wrote: > 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. Uhm, you are right here, it's not racy. Sorry, I had read the code quickly and didn't notice the i2c_new_dummy_device() call. So this means if i2c_new_alias_device() succeeds but the caller later fails while applying the alias, then it has to call i2c_unregister_device() to free the alias. Correct? >>> 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. OK, I'm still uncomfortable with sending unexpected transactions to the dark outer space, but this is more a feeling than based on facts, and you know more than me, so I guess I can live with that. > Also, all the best for you in 2020! Thanks. Best wishes to you too for the new year! -- Luca
