Brad Campbell
Brad Campbell
A capsule that exposes `I2CDevice` to userspace would work.
The existing virtual_i2c layer could be used to provide `I2CDevice`s for both kernel drivers and userspace.
I don't think it makes sense to provide an I2CDevice to a kernel driver, and then also provide access to the same device (address) via a low level bus interface...
My proposed workflow: 1. main() instantiates `I2CDevice`s for each I2C device on the board. 2. main provides some of the `I2CDevice`s to in-kernel drivers. 3. main instantiates one or more...
> Yes. This PR does not address the existing issues with the I2C syscall drivers. The drivers are already used and enabled by default on a range of Tock boards,...
> How can userspace know which devices have been exposed? Is userspace supposed to just brute force syscall numbers? How does userspace know which syscall corresponds to which device? How...
> If the issue is specifically the `set_address()` it could be taken out of the HIL. This is the issue. We absolutely cannot add this API to `I2CDevice` HIL. >...
I think a design where the I2C mux exposes the "rest" of the I2C bus as a separate object would be workable. I don't think it should be called `I2CDevice`...
I'm still nervous about adding the `nmea_i2c` driver that has ambiguous expectations, and has all the drawbacks of UART with the overhead of I2C. I think if we are going...
> First, the interface from the process's perspective is "please give me, and only me, the next sentence from NMEA immediately." This may fail if someone else is concurrently reading,...