Hi Laurent, > > + i2c_lock_bus(adap, I2C_LOCK_SEGMENT); > > + > > + for (addr = 0x08; addr < 0x78; addr++) { > > + ret = i2c_scan_for_client(adap, addr, i2c_unlocked_read_byte_probe); > > + if (ret == -ENODEV) { > > + alias = i2c_new_dummy_device(adap, addr); > > + dev_dbg(&adap->dev, "Found alias: 0x%x\n", addr); > > + break; > > + } > > + } > > This looks quite inefficient, especially if the beginning of the range > is populated with devices. Well, we have to start somewhere? And actually, the range from 0x08 onwards is the least used I encountered so far. What would you suggest? > 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. Another call to > i2c_new_alias_device() could occur in-between. This is why the whole function is protected using i2c_lock_bus. No other device can scan simultaneously. And once we have the dummy device registered, it is blocked like any other registered device. As we register the dummy device with the lock being held, I don't see how the above race can happen. > There's also the issue > that I2C hasn't been designed for scanning, so some devices may not > appreciate this. This is inevitable. What GMSL and FPD-Link do is very non-I2Cish. I don't see a "perfect" solution. We could skip this transaction and rely only on that all devices are pre-registered. Yet, I think the requirement that all busses *must* be fully described is more dangerous. I'd rather risk that some rare device doesn't like the transaction. I think a byte_read is the best we can do. Much better than a quick command, for sure. > What happened to the idea of reporting busy address ranges in the > firmware (DT, ACPI, ...) ? Fully in place. All pre-registered devices won't be considered because i2c_scan_for_client() uses i2c_check_addr_busy(). Did you think the new helper only relies on the transfer sent out? This is not the case, the transfer is only the final safety measure for so far unclaimed addresses. All the best for 2020, Wolfram