Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp851347rwb; Fri, 23 Sep 2022 05:09:39 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5ETitnPoVQgAvvKY4gv2xBYnpcGRBfrYfrJAB7dZYT543USbCTW7FGmdGYOE+frNtxkPEt X-Received: by 2002:a17:907:94c6:b0:77d:7ad3:d063 with SMTP id dn6-20020a17090794c600b0077d7ad3d063mr6777292ejc.330.1663934978985; Fri, 23 Sep 2022 05:09:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663934978; cv=none; d=google.com; s=arc-20160816; b=p7S3KqSMl0GBuB2/a40XuTuqL6p0ibUkNkdVz5y1vFblCVBP1T5P15Ev+2ZP7vpcWy Z2FJc35RcfXlCDAE9PdhyhfgAYb2fOtSbt/AP2OXaz89MjbaFaGBd3Fxo9XmaXa96Roo GoWPeydCHcL3Iqjp4ZXyUkJtN6WYENnDLEKxTDAmXGre7b395SWGPD3Ef3Q0Wz8Br9tJ noz6lOldqyTnmkE1wLLR7Uv9aG7UPmrbbnhDz4kfSvkMwCDovgQujTULSpVfWAWDr/YG am5xb6mDEtHckk0e9f9jM60HRBryuMJ+/aIf9l2wMY9/juLl+zGIJo5BLixpTWeb+mA3 odAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:feedback-id :dkim-signature:dkim-signature; bh=U8iCHLFAXA03KunxPFzc62aKiSEd/kuLZlf3yHGCKvs=; b=E5xc5Ps0Ar6ZT3c72SywVZJMcqsFmWulJOLl21P9EjkCndRAvpoCRNDC0LiBhiFPPW vfEQeg+5FCvKUXQ1FoBxtpTKv/Zg+PdzZyhXqBjB4kkZm4moRwaMtBbiVKOrqlBGjY1n 9YDjCBQDmdVF2MsSi2tIXatSM1iDFm1eqj9FZ685xb1Mj/SLCAfZn4LucLUD46ECyryJ 3bqlTQUvsndcv9A/i9d8WSKaxOfYWN0BqOlJXzh0luigqI21tD0t1WmCxRmLH5venaaU g2z96cYZfJw6XDq0UQxDu8m2RtlxebsQkLaZirwH0P19+3W0Q1n7L0t0dJN6Hz2DSC4Q sosQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cerno.tech header.s=fm2 header.b=KnfxfY7X; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=1GhdtXSm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=cerno.tech Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k17-20020a170906129100b0077081057215si6985015ejb.956.2022.09.23.05.09.13; Fri, 23 Sep 2022 05:09:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@cerno.tech header.s=fm2 header.b=KnfxfY7X; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=1GhdtXSm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=cerno.tech Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231534AbiIWLOQ (ORCPT + 99 others); Fri, 23 Sep 2022 07:14:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229794AbiIWLOO (ORCPT ); Fri, 23 Sep 2022 07:14:14 -0400 Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 993831280FE for ; Fri, 23 Sep 2022 04:14:12 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id EC446580219; Fri, 23 Sep 2022 07:14:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 23 Sep 2022 07:14:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1663931649; x=1663938849; bh=U8iCHLFAXA 03KunxPFzc62aKiSEd/kuLZlf3yHGCKvs=; b=KnfxfY7Xan2R/4k1btc8AOnQ76 iapL04VVpwC3mc47Xy7W1ybrnD1B+GsvXIFtI8NCivc/3NvvFhKrGjyRSf8zqmBz h3oyGPndxWxRVfRDpUbc14sX5bSTJRat1pJNcdLKnFL5W5nTaYifVgElOvGp3KI+ E9ax4ZkmVl6Z6BzFFIWjoZCeiSLc9HbAPr4f2xBDj7sW2WlZXAdybWq89LsngniV qDW59Qe5U4EnPdR3A+qAJI23fz97G00Jv7VBIbTDTaUawwJ0ohiBcYjqLlWgjgLf PnkoBElktz7rXP6uSVg98fzU5ETzORxC1FsOl1x+Qro/sgqAXssRV57flcgw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1663931649; x=1663938849; bh=U8iCHLFAXA03KunxPFzc62aKiSEd /kuLZlf3yHGCKvs=; b=1GhdtXSmXpYbKvsFs9JbbeWnAKG2XGmX2scD84UrYBfi 5xsixll0/LQ9aZAnSFbrIUAh7jhK+uHTI2CUCZOfTgeCNwOKTg9k62U1eUCB2DBh kacuKD6ef9jZMedV6A7BDHPVujQQTga5+oQ/4ZNh3DZwP6OZvlR6gXGtRyU41V7t MoRZY8CdMqeG8L/U7N/B5MHYo7cFlxftdjPOjHJlb8wEaf3aprvkdwwO7Dcz4zEJ O6ybqeci288KeYjzCMFo1kPDOc0XickXrQo5fe1K9Jgh3uYx09LFELjFkvhhqBLp sc62E8aLibgzZhAMlGZX/8msotG7GTWkc7tjH8aPxg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeefiedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpeelueejheffvdetueeugfelteeigedtgfejvdfhffegjeehffekjeetgfef jeektdenucffohhmrghinhepkhhunhhithdruggvvhenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 23 Sep 2022 07:14:08 -0400 (EDT) Date: Fri, 23 Sep 2022 13:14:05 +0200 From: Maxime Ripard To: Thomas Zimmermann Cc: Javier Martinez Canillas , Jernej Skrabec , Rodrigo Vivi , Ben Skeggs , David Airlie , Joonas Lahtinen , Emma Anholt , Karol Herbst , Samuel Holland , Jani Nikula , Daniel Vetter , Lyude Paul , Maarten Lankhorst , Tvrtko Ursulin , Chen-Yu Tsai , Dom Cobley , Dave Stevenson , Phil Elwell , nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Mateusz Kwiatkowski , Hans de Goede , Noralf =?utf-8?Q?Tr=C3=B8nnes?= , Geert Uytterhoeven , linux-sunxi@lists.linux.dev, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode() Message-ID: <20220923111405.mnspcuiwfzxyxix6@houat> References: <20220728-rpi-analog-tv-properties-v2-0-f733a0ed9f90@cerno.tech> <20220728-rpi-analog-tv-properties-v2-13-f733a0ed9f90@cerno.tech> <49ea7c7c-7d4c-8348-ea75-e0f376111e4c@suse.de> <93969920-b5ed-ff15-48d4-02e2f9c23505@suse.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4cwm4b5gx3ebmiqr" Content-Disposition: inline In-Reply-To: <93969920-b5ed-ff15-48d4-02e2f9c23505@suse.de> X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --4cwm4b5gx3ebmiqr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 23, 2022 at 12:30:09PM +0200, Thomas Zimmermann wrote: > Am 23.09.22 um 11:26 schrieb Javier Martinez Canillas: > > On 9/23/22 11:15, Thomas Zimmermann wrote: > > > Hi > > >=20 > > > Am 22.09.22 um 16:25 schrieb Maxime Ripard: > > > > drm_connector_pick_cmdline_mode() is in charge of finding a proper > > > > drm_display_mode from the definition we got in the video=3D command= line > > > > argument. > > > >=20 > > > > Let's add some unit tests to make sure we're not getting any regres= sions > > > > there. > > > >=20 > > > > Signed-off-by: Maxime Ripard > > > >=20 > > > > diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm= /drm_client_modeset.c > > > > index bbc535cc50dd..d553e793e673 100644 > > > > --- a/drivers/gpu/drm/drm_client_modeset.c > > > > +++ b/drivers/gpu/drm/drm_client_modeset.c > > > > @@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client= _dev *client, int mode) > > > > return ret; > > > > } > > > > EXPORT_SYMBOL(drm_client_modeset_dpms); > > > > + > > > > +#ifdef CONFIG_DRM_KUNIT_TEST > > > > +#include "tests/drm_client_modeset_test.c" > > > > +#endif > > >=20 > > > I strongly dislike this style of including source files in each other. > > > It's a recipe for all kind of build errors. Can you do something else? > > >=20 > >=20 > > This seems to be the convention used to test static functions and what's > > documented in the Kunit docs: https://kunit.dev/third_party/kernel/docs= /tips.html#testing-static-functions >=20 > That document says "...one option is to conditionally #include the test > file...". This doesn't sound like a strong requirement. No, but this is the only option documented, which still indicates a very strong preference. > > I agree with you that's not ideal but I think that consistency with how > > it is done by other subsystems is also important. > > > As the tested function is an internal interface, maybe export a wrapp= er > > > if tests are enabled, like this: > > >=20 > > > #ifdef CONFIG_DRM_KUNIT_TEST > > > struct drm_display_mode * > > > drm_connector_pick_cmdline_mode_kunit(drm_conenctor) > > > { > > > return drm_connector_pick_cmdline_mode(connector) > > > } > > > EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit) > > > #endif > > >=20 > > > The wrapper's declaration can be located in the kunit test file. And I'm afraid this just doesn't scale. If we start testing more and more static functions, do we really want to have that wrapper for each of them? > > But that's also not nice since we are artificially exposing these only > > to allow the static functions to be called from unit tests. And would > > be a different approach than the one used by all other subsystems... > >=20 >=20 > There's the problem of interference between the source files when building > the code. It's also not the same source code after including the test fil= e. > At a minimum, including the tests' source file further includes more file= s. > also includes quite a few of Linux header files. >=20 > IMHO the current convention (if any) is far from optimal and we should > consider breaking it. I mean... this is a discussion about theoretical issues. If there is indeed some regular build errors on this, then sure, we can change it. I'm confident that will affect pretty much every one using kunit equally though, so I'm fairly sure the documentation itself will have changed. But right now we're discussing an alternative because of a problem we never experienced. I don't see the point of breaking the consistency provided by the documentation for something not backed by any actual problem. Maxime --4cwm4b5gx3ebmiqr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYy2U/QAKCRDj7w1vZxhR xbjnAQDguqVberZj4t3P9J7J+oQg19WB9p14JwDj9eYuF79RiAEAjgZAHDUtrTKk vCbaI/ojPoO94K+YindeHthKWzTZrwo= =uI0t -----END PGP SIGNATURE----- --4cwm4b5gx3ebmiqr--