On Mon, 28 Feb 2022 23:26:05 -0300 Marcelo Schmitt <marcelo.schmi...@gmail.com> wrote:
> Hi, > > I'd like to know the opinion of the QEMU community on some topics. > > In 2021, a pair of patch sets for drivers of the Linux IIO subsystem was > proposed based on some QEMU hacks that added virtual devices with which > it was possible to test the proposed modifications to the Linux kernel > [1, 2, 3]. > > Most Linux IIO drivers connect to the system through either SPI or I2C. > So, it ends up that these buses are needed to do some tests on IIO > drivers. Because of that, those QEMU changes included hacks to the virt > platform to add SPI or I2C buses. > > The documentation says that virt is a generic virtual platform [4]. In > this regard, adding more buses to virt could turn the platform into > something less generic. However, if support for SPI/I2C were added, then > it would reduce the effort needed to develop virtual devices to aid > driver testing. Before putting effort to develop something concrete, I'd > like to ask just to make sure: > Would SPI/I2C support be a good addition to QEMU virt? Hi Marcelo, With my IIO kernel maintainer hat on, I'm keen to have a better platform for this than my various hacks so very happy to see this topic raised! The advantage of arm-virt is the setup code and dt/acpi table generation is all more or less in one place which makes things nice and flexible for configuration. It might be possible to do something that is well isolated in separate file optionally built/runtime enabled so as to not bloat arm-virt for other usecases. Trying to enable generic configuration for i2c and spi devices is via -device looks hard to me as there are normally gpio/irq type requirements but perhaps it can be done and that would make things more flexible. Mind you for a test platform I have no problem with having a 'board' that has lots of i2c and SPI devices always configured. > > Another possibility would be to add support for SPI and I2C buses on > Raspberry Pi boards emulation [5]. Would this be a better idea? It would be an option though maybe not so easy to mess around with and extending those with devices not commonly seen might also be controversial. Thinking out of the box, we could emulate a PCI card and put everything on that but we'd probably be inventing hardware to emulate as I don't know of a suitable device. There are real usb-i2c/spi devices but those aren't entirely trivial to use and you still need to describe non discoverable buses somehow. > > Also, the QEMU devices developed could be upstreamed. At first, I > thought that developing virtual devices would be a win-win situation in > which we could extend Linux's test coverage and add support for new QEMU > devices. However, as these would be dummy devices, I'm not sure how QEMU > would benefit from them. Anyhow, I'd appreciate it if anyone could give > a word about that. Needs someone to commit to maintaining the code + tests etc. Whilst I don't mind helping, I don't have the bandwidth to do too much on this in Qemu, but sounds like you might be the perfect person Marcelo :) Jonathan > > > Thanks, > Marcelo > > [1] > https://lore.kernel.org/linux-iio/20210314181511.531414-1-ji...@kernel.org/ > [2] > https://lore.kernel.org/linux-iio/20210614113507.897732-1-ji...@kernel.org/ > [3] https://github.com/jic23/qemu > [4] https://qemu-project.gitlab.io/qemu/system/arm/virt.html > [5] https://qemu-project.gitlab.io/qemu/system/arm/raspi.html >
