On Mon, Dec 02, 2024 at 02:07:36PM +0200, Jani Nikula wrote:
> On Mon, 02 Dec 2024, Maxime Ripard <mripard@xxxxxxxxxx> wrote:
> > It's not about whether we have a problem or not: you introduce new
> > framework functions, you need to have kunit tests to check their
> > behaviour.
>
> I don't fundamentally disagree with that goal, but it does seem like a
> pretty drastic policy change. I don't recall a discussion where we made
> that decision, nor can I find any documentation stating this. Or what
> exactly the requirement is; it's totally unclear to me.
>
> Had I been involved, I would've pointed out that while adding tests is
> good, it inevitably increases the friction of adding new stuff to drm
> core. It's super tempting for people to just get their jobs done. If
> doing the right thing adds yet another hurdle, we may see more stuff
> being added in drivers instead of drm core.
>
> (Case in point, we already hacked around the problem being solved here
> with commit d58f65df2dcb ("drm/i915/dp_mst: Fix connector initialization
> in intel_dp_add_mst_connector()"). We could've just dropped the ball
> right there.)
Fwiw, in this case adding tests for drm_connector_init_core() and
drm_connector_add() looks simple enough.
IIUC it's the 3 testcases in drmm_connector_init_tests[] performed for
drm_connector_init_core() and additional 3 test cases checking that (1)
drm_connector_init_core() doesn't add the connector to the connector
list, (2) drm_connector_add() adds it and (3) drm_connector_add() fails
(by not adding the connector to the list and emitting a dmesg WARN) if
drm_connector_init_core() was not called for the connector previously.
For the last test I actually need to add the corresponding assert/early
return to drm_connector_add().
If Maxim could confirm the above, I could resend the patchset adding
these tests.
--Imre
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel
