On 11/28/22 15:53, Maxime Ripard wrote:
> The HVS to PixelValve muxing code is fairly error prone and has a bunch
> of arbitrary constraints due to the hardware setup.
>
> Let's create a test suite that makes sure that the possible combinations
> work and the invalid ones don't.
>
> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
> ---
Thanks for this patch. It shows how powerful KUnit can be for testing drivers.
Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 11/28/22 15:53, Maxime Ripard wrote:
> Accessing a register when running under kunit is a bad idea since our
> device is completely mocked.
>
> Fail the current test if we ever access any of our hardware registers.
>
> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
> ---
[...]
> -#define CRTC_WRITE(offset, val) writel(val, vc4_crtc->regs + (offset))
> -#define CRTC_READ(offset) readl(vc4_crtc->regs + (offset))
> +#define CRTC_WRITE(offset, val) \
> + do { \
> + kunit_fail_current_test("Accessing a register in a unit test!\n"); \
> + writel(val, vc4_crtc->regs + (offset)); \
> + } while (0)
> +
> +#define CRTC_READ(offset) \
> + ({ \
> + kunit_fail_current_test("Accessing a register in a unit test!\n"); \
> + readl(vc4_crtc->regs + (offset)); \
> + })
>
Should this be made conditional on whether DRM_VC4_KUNIT_TEST is enabled ?
That is, just define the simpler macros when is disabled? The kunit_fail_current_test()
is just a no-op if CONFIG_KUNIT isn't enabled, but I think my question still stands.
Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 11/28/22 15:53, Maxime Ripard wrote:
> Some tests will need to provide their own drm_driver instead of relying
> on the dumb one in the helpers, so let's create a helper that allows to
> do so.
>
> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
> ---
Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 11/28/22 15:53, Maxime Ripard wrote:
> The current helper to allocate a DRM device doesn't allow for any
> subclassing by drivers, which is going to be troublesome as we work on
> getting some kunit testing on atomic modesetting code.
>
> Let's use a similar pattern to the other allocation helpers by providing
> the structure size and offset as arguments.
>
> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
> ---
[...]
> -EXPORT_SYMBOL(drm_kunit_helper_alloc_drm_device);
> +EXPORT_SYMBOL(__drm_kunit_helper_alloc_drm_device);
>
I'm not sure if I would add a __ prefix to exported symbols, but I see that
this is a convention in the DRM subsystem so I'm OK with it.
Another thing that came to mind is if we want to use EXPORT_SYMBOL_GPL()
instead for the DRM KUnit helpers. But that's not related to this series.
Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Before this series, only the initiator of a connection was able to combine both
TCP FastOpen and MPTCP when using TCP_FASTOPEN_CONNECT socket option.
These new patches here add (in theory) the full support of TFO with MPTCP, which
means:
- MSG_FASTOPEN sendmsg flag support (patch 1/8)
- TFO support for the listener side (patches 2-5/8)
- TCP_FASTOPEN socket option (patch 6/8)
- TCP_FASTOPEN_KEY socket option (patch 7/8)
To support TFO for the server side, a few preparation patches are needed
(patches 2 to 5/8). Some of them were inspired by a previous work from Benjamin
Hesmans.
Note that TFO support with MPTCP has been validated with selftests (patch 8/8)
but also with Packetdrill tests running with a modified but still very WIP
version supporting MPTCP. Both the modified tool and the tests are available
online:
https://github.com/multipath-tcp/packetdrill/
Dmytro Shytyi (5):
mptcp: add MSG_FASTOPEN sendmsg flag support
mptcp: implement delayed seq generation for passive fastopen
mptcp: add subflow_v(4,6)_send_synack()
mptcp: add TCP_FASTOPEN sock option
selftests: mptcp: mptfo Initiator/Listener
Matthieu Baerts (1):
mptcp: add support for TCP_FASTOPEN_KEY sockopt
Paolo Abeni (2):
mptcp: track accurately the incoming MPC suboption type
mptcp: consolidate initial ack seq generation
net/mptcp/Makefile | 2 +-
net/mptcp/fastopen.c | 73 ++++++++
net/mptcp/options.c | 25 ++-
net/mptcp/protocol.c | 39 +---
net/mptcp/protocol.h | 28 ++-
net/mptcp/sockopt.c | 9 +-
net/mptcp/subflow.c | 105 ++++++++---
.../selftests/net/mptcp/mptcp_connect.c | 171 +++++++++++++-----
.../selftests/net/mptcp/mptcp_connect.sh | 21 +++
9 files changed, 358 insertions(+), 115 deletions(-)
create mode 100644 net/mptcp/fastopen.c
Cc: Benjamin Hesmans <benjamin.hesmans(a)tessares.net>
base-commit: a6e3d86ece0b42a571a11055ace5c3148cb7ce76
--
2.37.2