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