From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F8D7C4332F for ; Mon, 28 Nov 2022 18:14:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233059AbiK1SOo (ORCPT ); Mon, 28 Nov 2022 13:14:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231856AbiK1SOZ (ORCPT ); Mon, 28 Nov 2022 13:14:25 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D44562C675 for ; Mon, 28 Nov 2022 09:56:42 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6FF4F61337 for ; Mon, 28 Nov 2022 17:56:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 949BDC433C1; Mon, 28 Nov 2022 17:56:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669658201; bh=UHB0IwCURSW0ZfKKegBbpDFFLahEIyT+jw1tKJBPgQA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BPJykboQTxYwAajFdfUb+fgsXJFMjWlrNgN+11r0CASINzJOiVBby068faMLEGGLX FvomxjyEbz9Q4UipVVDl/Wn7jUhGb0cwxt3hIAL1B358BDhoecRhwfls4FPOwJAu+u H8gd3Yx7GJJ3R/Z/AOGDoJNhlmTh1r1xEYFYF4aTtpy8w3kZEiMy42DiVDhOYsxH2t ZXCKxHmvYHZqdOB41oOkG5G7siJr98TbzOnn/xTZvAMAgwzTHQAeDALK4fU+0Vdcni GrBsaUhZQD5fSV0SSwMhpdyFc9drr9Av2OriSICynRl9sk0f1BUuN02PKwk+gR/Olo y8JWltUebR8wQ== Date: Mon, 28 Nov 2022 17:56:37 +0000 From: Mark Brown To: Jean Delvare Cc: LKML , Liam Girdwood , Jaroslav Kysela , Takashi Iwai Subject: Re: [PATCH] ASoC: rsnd: Drop obsolete dependency on COMPILE_TEST Message-ID: References: <20221127193441.0b54484d@endymion.delvare> <20221128145612.74ff3d25@endymion.delvare> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UhrjA2DqVOp+T3Oa" Content-Disposition: inline In-Reply-To: <20221128145612.74ff3d25@endymion.delvare> X-Cookie: In the next world, you're on your own. Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --UhrjA2DqVOp+T3Oa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 28, 2022 at 02:56:12PM +0100, Jean Delvare wrote: > On Mon, 28 Nov 2022 12:33:35 +0000, Mark Brown wrote: > > On Sun, Nov 27, 2022 at 07:34:41PM +0100, Jean Delvare wrote: > > > It is actually better to always build such drivers with OF enabled, > > > so that the test builds are closer to how each driver will actually be > > > built on its intended target. Building them without OF may not test > > > much as the compiler will optimize out potentially large parts of the > > > code. In the worst case, this could even pop false positive warnings. > > > Dropping COMPILE_TEST here improves the quality of our testing and > > > avoids wasting time on non-existent issues. =20 > > As ever building without OF does not preclude building with OF. > I'm sorry, I'm not sure I understand what point you are trying to make > here. You're overselling what the change does here in a way that's getting a bit silly. It's just cutting down the amount of stuff the randconfig people do, that's all. It's not particularly bad to compile without the DT support, I suppose you could argue that it's preserving our ability to work with other firmware interfaces although that's a bit of a push (but then a lot of the stuff generated by randconfig is in a similar ballpark of course). The whole point with COMPILE_TEST is that it's enabling unrealistic things that probably aren't practically useful. > That's true, but it's a matter of quantity versus quality. Would you > rather test build the code twice in its crippled form, which may > trigger false-positive warnings or hide actual warnings, or just once > in its proper form, where all warnings and build failures are real? I > definitely believe the latter is a better use of our resources. I'm not saying don't do the change, I'm saying don't oversell it. --UhrjA2DqVOp+T3Oa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmOE9lQACgkQJNaLcl1U h9BggQf/a4D/DUNNFiONMXCiabuB3MAsolK1pNndM6oSMlyfrlWHjdrT/31nDehL yqTw6X1FSWpWEKAUwZLciIvtnvoLNFmT8+C6xDAcNVz5dbcqf16LC+HWWRccAlSp cF7iQr1SGRos3Mp81jMcM2584jzDKoVjH9oSqlZ21O0h7G9r+7gZrKh1DMI9T7Eg zgtV5aHG8UGnYrR9lznVekvIZaY/5YyLaYwDpK/4VXIWDWMO1ySBQetwojaqZf5m gQ8Xzg9LGq06DwBNcMoCnEeFV4EXyTeflp6NnbzfZCNoAXJKPRr+Fcg7n9gilAOl 4U2cZcjSdsS7zMb8sJQfVFzMMXc+bQ== =fCam -----END PGP SIGNATURE----- --UhrjA2DqVOp+T3Oa--