mbox series

[-next,0/4] spi: Introduce BPF based SPI mockup controller

Message ID 20220826144341.532265-1-weiyongjun1@huawei.com
Headers show
Series spi: Introduce BPF based SPI mockup controller | expand

Message

Wei Yongjun Aug. 26, 2022, 2:43 p.m. UTC
This series Introduce a BPF based SPI mockup controller, which can be
used for testing SPI drivers without real device.

The testsuite for SPI drivers will be post in other series, with also
support for I2C and PCI bus device drivers.

patch 1-2 introduce BPF based SPI mockup controller
patch 3 interface for dynamically add devices from dts, may use
        of-configfs insead
patch 4 add the document

Wei Yongjun (4):
  spi: mockup: Add SPI controller testing driver
  spi: mockup: Add writeable tracepoint for spi transfer
  spi: mockup: Add runtime device tree overlay interface
  spi: mockup: Add documentation

 Documentation/spi/index.rst       |   1 +
 Documentation/spi/spi-mockup.rst  | 201 +++++++++++++++++++
 drivers/spi/Kconfig               |  15 ++
 drivers/spi/Makefile              |   1 +
 drivers/spi/spi-mockup.c          | 315 ++++++++++++++++++++++++++++++
 include/linux/spi/spi-mockup.h    |  13 ++
 include/trace/events/spi_mockup.h |  32 +++
 7 files changed, 578 insertions(+)
 create mode 100644 Documentation/spi/spi-mockup.rst
 create mode 100644 drivers/spi/spi-mockup.c
 create mode 100644 include/linux/spi/spi-mockup.h
 create mode 100644 include/trace/events/spi_mockup.h

Comments

Mark Brown Aug. 30, 2022, 7:08 p.m. UTC | #1
On Fri, Aug 26, 2022 at 02:43:37PM +0000, Wei Yongjun wrote:
> This series Introduce a BPF based SPI mockup controller, which can be
> used for testing SPI drivers without real device.
> 
> The testsuite for SPI drivers will be post in other series, with also
> support for I2C and PCI bus device drivers.

I replied to some of the individual patches here with some more
detailed issues but I do have some big picture reservations with
this approach as well.  One big one is that this seems like it's
only going to be able to handle emulation of devices that are
purely synchronous - I don't see any sensible direction here for
extending to devices that need an interrupt line as well.  That
seems like a major limitation.  It's fine not to immediately
implement everything but it should be fairly clear how that would
be done when someone needs it and some of the BPF design goals I
understood seem to conflict with that.

I'm also not clear what the BPF environment is like when it comes
to extensible frameworks, as soon as you start thinking about the
problem space there are some obvious extensions with things like
more detailed register map descriptions and validating that the
operations that the driver is doing to the device are actually in
spec for the device or trying to stimulate race conditions or
error paths in the driver.

There's also the issue with getting the BPF userspace tooling
that I mentioned in reply to one of the individual patches.

Basically while this does look very simple from a kernel point of
view I worry that BPF might not be the right tool for the job and
could be a bit of a blind alley, with people rapidly running into
issues trying to do anything non-trivial.

There was a series in the past year or so from someone
implementing a similarish idea but rather than using BPF they
provided a framework for writing device emulations in qemu with
a simplified Python framework.  That seemed like a more obvious
direction here.  They were initially focusing on I2C but it's a
similar space.  Unfortunately I'm drawing a blank on who was
working on it or the name of the framework so I can't give a
useful reference here.  Their direction was towards having
something that could also be used to validate what the driver was
doing to the device from the device's perspective.  I do know it
was written up on LWN.  Hopefully someone else will remember what
I'm talking about from this vauge description.
Mark Brown Sept. 1, 2022, 10:38 a.m. UTC | #2
On Tue, Aug 30, 2022 at 08:09:16PM +0100, Mark Brown wrote:

> There was a series in the past year or so from someone
> implementing a similarish idea but rather than using BPF they
> provided a framework for writing device emulations in qemu with
> a simplified Python framework.  That seemed like a more obvious
> direction here.  They were initially focusing on I2C but it's a
> similar space.  Unfortunately I'm drawing a blank on who was
> working on it or the name of the framework so I can't give a
> useful reference here.  Their direction was towards having
> something that could also be used to validate what the driver was
> doing to the device from the device's perspective.  I do know it
> was written up on LWN.  Hopefully someone else will remember what
> I'm talking about from this vauge description.

The framework I was thinking of is called roadtest from Vincent
Whitchurch who I've copied in here.
Wei Yongjun Sept. 1, 2022, 12:23 p.m. UTC | #3
On 2022/8/31 3:08, Mark Brown wrote:
> On Fri, Aug 26, 2022 at 02:43:37PM +0000, Wei Yongjun wrote:
>> This series Introduce a BPF based SPI mockup controller, which can be
>> used for testing SPI drivers without real device.
>>
>> The testsuite for SPI drivers will be post in other series, with also
>> support for I2C and PCI bus device drivers.
> 
> I replied to some of the individual patches here with some more
> detailed issues but I do have some big picture reservations with
> this approach as well.  One big one is that this seems like it's
> only going to be able to handle emulation of devices that are
> purely synchronous - I don't see any sensible direction here for
> extending to devices that need an interrupt line as well.  That
> seems like a major limitation.  It's fine not to immediately


We can use gpio-sim as the interrupt controller which always exists
with some tiny fix, I had posted them and can be found from link:

https://www.spinics.net/lists/linux-gpio/msg74949.html


> implement everything but it should be fairly clear how that would
> be done when someone needs it and some of the BPF design goals I
> understood seem to conflict with that.
> 
> I'm also not clear what the BPF environment is like when it comes
> to extensible frameworks, as soon as you start thinking about the
> problem space there are some obvious extensions with things like
> more detailed register map descriptions and validating that the
> operations that the driver is doing to the device are actually in
> spec for the device or trying to stimulate race conditions or
> error paths in the driver.


The bpftool in kernel still need some works, I am still working on
fix comments from maintainers, which can be found at:

https://lore.kernel.org/bpf/b942bf8f-204b-6bf1-7847-ec5f11c50ca0@isovalent.com/

> 
> There's also the issue with getting the BPF userspace tooling
> that I mentioned in reply to one of the individual patches.
> 
> Basically while this does look very simple from a kernel point of
> view I worry that BPF might not be the right tool for the job and
> could be a bit of a blind alley, with people rapidly running into
> issues trying to do anything non-trivial.
> 

Base on BPF's map, we can using wrap for read/write registers as
the device's requirement. And it is possible to control each register
and runtime.

For example, simple write data to MTD device, and check whether
the data is write to registers:

def test_write_data(self):
    with self.device() as dev:
         self.device_write_bytes(dev, [1, 2, 3, 4]) <- write to /dev/mtd
         data = self.read_regs(0x00, 4)
         self.assertEqual(data, [1, 2, 3, 4])

I am working on a light weight framework which just 400 loc's python
code, and can do similar tests to roadtest.

Once I finished the bpftool, I will post a proposal.

> There was a series in the past year or so from someone
> implementing a similarish idea but rather than using BPF they
> provided a framework for writing device emulations in qemu with
> a simplified Python framework.  That seemed like a more obvious
> direction here.  They were initially focusing on I2C but it's a
> similar space.  Unfortunately I'm drawing a blank on who was
> working on it or the name of the framework so I can't give a
> useful reference here.  Their direction was towards having
> something that could also be used to validate what the driver was
> doing to the device from the device's perspective.  I do know it
> was written up on LWN.  Hopefully someone else will remember what
> I'm talking about from this vauge description.
> 

I saw your other mail, and know you mean roatest, which is based on
virtio as the backend.

The bpf backend can be easily integrate to roadtest.


Regards,
Wei Yongjun