On Mon, Dec 02, 2024 at 04:07:56PM +0100, Maxime Ripard wrote:
> On Mon, Dec 02, 2024 at 03:24:43PM +0200, Imre Deak wrote:
> > 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.
>
> Yep, sounds great, thanks!
Ok. The subtest (3) above checking if drm_connector_add() fails as
expected if drm_connector_init_core() was not called before would also
generate a dmesg warn, via a
if (drm_WARN_ON(dev, !connector->funcs))
return;
early return I'm adding to drm_connector_add() in the new version of the
patchset. This fails the kunit test, as always when an error or warn is
printed to the log. I couldn't find a good way to suppress this warn
(don't want to modify the function being tested) to make the testcase
pass. I think this test case could be omitted, since it's tested by all
users implicitly anyway via the above assert. Is this acceptable?
> Maxime
