All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: Imre Deak <imre.deak@intel.com>,
	intel-gfx@lists.freedesktop.org,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Dave Airlie <airlied@redhat.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	dri-devel@lists.freedesktop.org,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH v2 1/4] drm/dp: Add a way to init/add a connector in separate steps
Date: Tue, 03 Dec 2024 13:17:58 +0200	[thread overview]
Message-ID: <87v7w13ti1.fsf@intel.com> (raw)
In-Reply-To: <20241203-simple-pigeon-of-infinity-babfee@houat>

On Tue, 03 Dec 2024, Maxime Ripard <mripard@kernel.org> wrote:
> On Mon, Dec 02, 2024 at 05:44:27PM +0200, Jani Nikula wrote:
>> >> 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 obviously misinterpreted what you were saying then. Sorry for the
> whole tone of that mail.

Don't worry about it. Likewise, my mail wasn't a stellar example of
communication either. Sorry about that. Let's move on.

>> 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.
>
> Right, but I don't think it's worth worrying over either. If one stops
> contributing because they are afraid of running one documented command
> that takes a few seconds, they would have done so at any other obstacle.
> We have much bigger barriers of entry, at several levels.
>
> All of them are here for a good reason, and because we have collectively
> judged that the trade-off between adding a barrier and increasing the
> quality of the framework was worth it.
>
> I believe tests are worth it too.
>
> But anyway, it's really not what I had in mind.

Would you mind drafting some ground rules for what you think the
requirements for kunit tests should be? What's the bare minimum, what's
the goal?

BR,
Jani.


-- 
Jani Nikula, Intel

  reply	other threads:[~2024-12-03 11:18 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-26 16:18 [PATCH v2 0/4] drm/dp: Expose only a properly inited connector Imre Deak
2024-11-26 16:18 ` [PATCH v2 1/4] drm/dp: Add a way to init/add a connector in separate steps Imre Deak
2024-11-29 14:26   ` Imre Deak
2024-11-29 14:46     ` Maxime Ripard
2024-11-29 15:58       ` Jani Nikula
2024-12-02 10:45         ` Maxime Ripard
2024-11-29 16:12       ` Imre Deak
2024-12-02 10:48         ` Maxime Ripard
2024-12-02 12:07           ` Jani Nikula
2024-12-02 13:24             ` Imre Deak
2024-12-02 15:07               ` Maxime Ripard
2024-12-02 15:31                 ` Imre Deak
2024-12-02 15:06             ` Maxime Ripard
2024-12-02 15:44               ` Jani Nikula
2024-12-03  9:36                 ` Maxime Ripard
2024-12-03 11:17                   ` Jani Nikula [this message]
2024-12-02 16:35   ` Simona Vetter
2024-12-02 20:07     ` Imre Deak
2024-12-06 20:48       ` Simona Vetter
2024-11-26 16:18 ` [PATCH v2 2/4] drm/i915/dp_mst: Expose a connector to kernel users after it's properly initialized Imre Deak
2024-11-26 16:18 ` [PATCH v2 3/4] drm/i915/dp_mst: Fix error handling while adding a connector Imre Deak
2024-11-26 16:18 ` [PATCH v2 4/4] drm/i915/dp_mst: Use intel_connector vs. drm_connector pointer in intel_dp_mst.c Imre Deak
2024-11-26 16:51 ` ✗ Fi.CI.SPARSE: warning for drm/dp: Expose only a properly inited connector Patchwork
2024-11-26 17:05 ` ✓ i915.CI.BAT: success " Patchwork
2024-11-26 18:30 ` ✗ i915.CI.Full: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v7w13ti1.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=airlied@redhat.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.