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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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,

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.

> 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.

You also know what increases the friction of adding new stuff? Adding
new stuff. Or writing documentation. Or writing commit log. Or sending
emails / making pull requests. Or asking for cross-reviews. Or having an
open-source user-space requirement. It seems pretty arbitrary to draw
the line right where testing starts.

> 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. And it's not like i915 is a great example
there.

> (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.)

Case in point indeed.

Maxime

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux