[PATCH v2 1/4] drm/dp: Add a way to init/add a connector in separate steps

[Jani Nikula]

On Mon, 02 Dec 2024, Maxime Ripard <mripard at kernel.org> wrote:
> On Mon, Dec 02, 2024 at 02:07:36PM +0200, Jani Nikula wrote:
>> On Mon, 02 Dec 2024, Maxime Ripard <mripard at kernel.org> 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,
>
> You don't really have to agree. You asked for my review, you have it.
>
>> 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.
>
> There isn't, because there's no such policy, even though it's definitely
> something I'd like. This situation is different though:
> drm_connector_init is already a function that is being tested. It seems
> natural to not dilute testing when adding new variant, disregarding what
> the policy of the rest of the framework is.

"You do X, you need do have Y" coming from a maintainer sure sounded
like hard rules. I was surprised.

>> 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.
>
> I really enjoy hidden threats.

None were implied. That's your interpretation of what I honestly think
is a plausible outcome. I try to push people towards contributing to drm
core instead of drivers, and it's not always easy as it is. It's just a
guess, but I'll bet the majority of drm contributors have never run
kunit tests themselves.

> And it's not like i915 is a great example there.

Sincerely, is this the level of discussion we really want to have?


BR,
Jani.


-- 
Jani Nikula, Intel