[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200429133923.GA18115@ravnborg.org>
Date: Wed, 29 Apr 2020 15:39:23 +0200
From: Sam Ravnborg <sam@...nborg.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
kbuild test robot <lkp@...el.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] video: fbdev: controlfb: fix build for COMPILE_TEST=y
&& PPC_PMAC=y && PPC32=n
Hi Christoph
On Wed, Apr 29, 2020 at 05:51:01AM -0700, Christoph Hellwig wrote:
> Why do we even bother allocing the driver to compile for !ppc32
> given that it clearly needs ppc-specific infrastructure? The whole
> idea of needing magic stubs for the COMPILE_TEST case seems rather
> counterproduction.
All the usual good arguments.
If this driver only builds for 32bit powerpc then we will seldom
build it and every time we do some refactoring we risk introducing
build errros in this driver that is triggered much later.
So a few hacks are preferred to actually make it build.
But hacks should not paper over missing abstractions
in the general ioremap handlign and such.
I recall someone said the other day that drm folks had a tendency to
workaround rather than fixing this.
So this is "drm folks" reaching out and asking if this is a
case where we have a workaround and need a fix?
I will - after some testing - apply the fix from Bartlomiej.
But would like to know if this is a workarond or a fix.
Dropping COMPILE_TEST is not an option as explained above.
Sam
Powered by blists - more mailing lists