This avoids the problem of a sensor that is has an accelerometer AND a
magnetometer as they will typically both use the same bus. In the case of
sensors that can use, say, I2C or SPI, you'd need 2 drivers anyway, so rather
than having /hw/drivers/sensors/bno055/spi/ and /hw/drivers/sensors/bno055/I2C
you'd have a bno055 driver in both the /hw/drivers/SPI and /hw/drivers/I2C
areas.
Missed this when I replied on my phone, sorry.
I can see the argument here, but to be honest I would rather maintain 1
driver that support both I2C and SPI simply because there is still a lot
of overlapping code above the transport. Registers, data conditioning,
etc., and there is a non neglible risk with two drivers that bugs get
fixed in one driver but not the other.
That said ... there isn't a clear right answer here. I'm worried about
what happens when you have 40-50 drivers in a flat folder, which is
entirely realistic over time since embedded generally = sensors,
although that still feels like the only solution that doesn't run into
problems quickly separating files by functionality or bus.
hw/drivers/sensors/<manufacturer>/<sensors_name> will reduce this to a
certain extent.
Another question is what about chips that aren't technically sensors:
* Motor drivers
* Display drivers or integrated displays (SSD1306, ILI9341, etc.)
These are all commonly used in embedded systems.
Perhaps a parent`ic` folder is a better label than 'sensors', so:
* hw/drivers/ic/display/ssd1306
* hw/drivers/ic/sensors/tls2561
* hw/drivers/ic/sensors/bno055
* hw/drivers/ic/motor/drv2605l
You don't want to end up with something 10 layers deep, but I think it
is important to keep this clean and well organised since it is bound to
be a key part of the system moving forward, although I expect a lot of
drivers will be stored outside the core repo of course.
K.
