linux-kernel - Re: [PATCH RESEND] drm/display: Drop obsolete dependency on COMPILE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD=FV=X4qVDTOdMFQeEiJi2DD=tuEj66vP35XQKrSj5-r_YADQ@mail.gmail.com>
Date: Mon, 17 Jun 2024 19:12:05 -0700
From: Doug Anderson <dianders@...omium.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Jean Delvare <jdelvare@...e.de>, dri-devel@...ts.freedesktop.org, 
	LKML <linux-kernel@...r.kernel.org>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>, 
	Andrew Morton <akpm@...ux-foundation.org>, YueHaibing <yuehaibing@...wei.com>
Subject: Re: [PATCH RESEND] drm/display: Drop obsolete dependency on COMPILE_TEST

Hi,

On Mon, Jun 17, 2024 at 3:26 PM Dmitry Baryshkov
<dmitry.baryshkov@...aro.org> wrote:
>
> On Mon, Jun 17, 2024 at 08:18:14PM GMT, Jean Delvare wrote:
> > On Mon, 17 Jun 2024 14:55:22 +0300, Dmitry Baryshkov wrote:
> > > On Mon, Jun 17, 2024 at 01:23:48PM GMT, Jean Delvare wrote:
> > > > Hi Dmitry,
> > > >
> > > > Thanks for your feedback.
> > > >
> > > > On Mon, 17 Jun 2024 12:57:19 +0300, Dmitry Baryshkov wrote:
> > > > > On Mon, Jun 17, 2024 at 10:30:30AM GMT, Jean Delvare wrote:
> > > > > > Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
> > > > > > is possible to test-build any driver which depends on OF on any
> > > > > > architecture by explicitly selecting OF. Therefore depending on
> > > > > > COMPILE_TEST as an alternative is no longer needed.
> > > > >
> > > > > The goal of this clause is to allow build-testing the driver with OF
> > > > > being disabled (meaning that some of OF functions are stubbed and some
> > > > > might disappear). I don't see how user-selectable OF provides the same
> > > > > result.
> > > >
> > > > Historically, the goal of this clause *was* to allow build-testing the
> > > > driver on architectures which did not support OF, and that did make
> > > > sense back then. As I understand it, building the driver without OF
> > > > support was never a goal per se (if it was, then the driver wouldn't be
> > > > set to depend on OF in the first place).
> > > >
> > > > Some of my other submissions include the following explanation which
> > > > you might find useful (I ended up stripping it on resubmission after
> > > > being told I was being too verbose, but maybe it was needed after all):
> > > >
> > > > 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.
> > >
> > > This doesn't seem to match the COMPILE_TEST usage that I observe in
> > > other places. For example, we frequently use 'depends on ARCH_QCOM ||
> > > COMPILE_TEST'. Which means that the driver itself doesn't make sense
> > > without ARCH_QCOM, but we want for it to be tested on non-ARCH_QCOM
> > > cases. I think the same logic applies to 'depends on OF ||
> > > COMPILE_TEST' clauses. The driver (DP AUX bus) depends on OF to be fully
> > > functional, but it should be compilable even without OF case.
> >
> > The major difference is that one can't possibly enable ARCH_QCOM if
> > building on X86 for example. Therefore COMPILE_TEST is the only way to
> > let everyone (including randconfig/allmodconfig build farms) test-build
> > your code.
> >
> > On the other hand, if you want to test-build drm_dp_aux_bus, you can
> > simply enable OF, because it is available on all architectures and
> > doesn't depend on anything. No need for COMPILE_TEST.
>
> I'd probably let Doug respond, what was his intention.

Is this me? This looks like a straight revert of commit 876271118aa4
("drm/display: Fix build error without CONFIG_OF")

I don't personally have anything against removing COMPILE_TEST for
this given that I wasn't the one who added it, but make sure it's not
going to cause randconfig issues.

-Doug