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;
MIME-Version: 1.0
References: <20230803144227.2187749-1-nogikh@google.com> <CAHCN7x+8Qq6w0eRC0NwBfhgS7XH7fmmPr9xwhR54rWFNY37Ugg@mail.gmail.com>
 <9e77ccc3-07db-f1fe-ef99-981852d4772b@infradead.org> <CAHCN7xKG=8ygSi8st31fe+t3Mn+k-7VUHKixFCZUuuDLOX8-kQ@mail.gmail.com>
 <d8a57aee-bb8a-dc5a-7c4f-b8a293d37bec@infradead.org> <CAHCN7xKnRAmKh60dAtVaxz-dQtjzhBNtS0aN2swmddfo5FAD-Q@mail.gmail.com>
 <b43e642d-8aa1-fb8a-6bff-86039a06d57b@infradead.org>
In-Reply-To: <b43e642d-8aa1-fb8a-6bff-86039a06d57b@infradead.org>
From:   Aleksandr Nogikh <nogikh@google.com>
Date:   Fri, 4 Aug 2023 12:19:44 +0200
Message-ID: <CANp29Y6_VcgQAHERdaXUqBZahfFkJ=ksvjVVeMkZz88Xxjz1jw@mail.gmail.com>
Subject: Re: drivers/gpu/drm/bridge/samsung-dsim.c link error
To:     Randy Dunlap <rdunlap@infradead.org>
Cc:     Adam Ford <aford173@gmail.com>, l.stach@pengutronix.de,
        inki.dae@samsung.com, jagan@amarulasolutions.com,
        m.szyprowski@samsung.com, airlied@gmail.com, daniel@ffwll.ch,
        dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        syzkaller@googlegroups.com, dvyukov@google.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Aug 4, 2023 at 4:47=E2=80=AFAM Randy Dunlap <rdunlap@infradead.org>=
 wrote:
>
> On 8/3/23 19:42, Adam Ford wrote:
> > On Thu, Aug 3, 2023 at 9:37=E2=80=AFPM Randy Dunlap <rdunlap@infradead.=
org> wrote:
> >>
> >> On 8/3/23 19:26, Adam Ford wrote:
> >>> Where/how was the .config generated?
> >>>
> >>
> >> Aleksandr posted a link to the config file above.
> >
> > I get that, but I am not sure how this was generated.
> >
>
> Nor am I. Alexsandr can hopefully tell us.

We take a defconfig and apply a number of modifications on top of it
(*). Some configs are enabled (e.g. various sanitizers), some are
disabled (e.g. a number of heavy subsystems are disabled for instances
that run on qemu w/o hardware acceleration).

We rely heavily on olddefconfig to detect inconsistencies during
config generation (we regenerate them manually once in a while and the
tool makes sure our changes do not contradict KConfigs) and to
automatically correct inconsistencies when a kernel is being
(re-)built (there's no other way -- something constantly changes in
the mainline tree and it's impossible to keep track of it all
manually).

In this particular case, we indeed disabled CONFIG_GENERIC_PHY, but
left other dependent configs enabled and `make olddefconfig` could
unfortunately neither help us detect the problem nor resolve it during
the build :(

(*) FWIW here's a doc for reference:
https://github.com/google/syzkaller/blob/master/dashboard/config/linux/READ=
ME.md

>
> >>
> >>> Are you building linux-next or something else?  The .config file
> >>> generated when I build the arm64 defconfig  show both enabled:
> >>
> >> linux-next.
> >>
> >>
> >>> $ grep GENERIC_PHY .config
> >>> CONFIG_GENERIC_PHY=3Dy
> >>> CONFIG_GENERIC_PHY_MIPI_DPHY=3Dy
> >>>
> >>
> >> Yes, this is not a defconfig file.
> >
> > I know, but it is a .config file that is generated from make defconfig
> > ARCH=3Darm64
> >>
>
> Not necessarily. It could be generated by 'make randconfig'.
>
> >>>
> >>>> but yes, selecting GENERIC_PHY (needed in 3 places) does fix the war=
nings
> >>>> and build error.  2 instance in drm/bridge/Kconfig and one in
> >>>> drm/bridge/cadence/Kconfig (found by inspection).
> >>>>
> >>>> I had no problem replicating the kconfig warnings and build error.
> >>>
> >>> If you can replicate the problem, I'd suggest submitting a patch.
> >>
> >> Sure, I'll do that.
> >
> > Great!  thanks.

I see the patch has already been sent. Thank you very much!

> >
> > adam
> >>
> >> --
> >> ~Randy
>
> --
> ~Randy