linux-kernel - Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set

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]

Date:	Mon, 23 Feb 2015 15:09:03 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Rob Clark <robdclark@...il.com>
Cc:	Archit Taneja <architt@...eaurora.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Daniel Vetter <daniel@...ll.ch>
Subject: Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set

On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote:
> On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja <architt@...eaurora.org> wrote:
> > The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is
> > selected. The driver accesses drm_fb_helper_* functions even when legacy fbdev
> > support is disabled in msm. Wrap around these functions with #ifdef checks to
> > prevent build break.
> 
> hmm, perhaps rather than solving this in each driver, we should do
> some stub versions of those fb-helper fxns?
> 
> There are at least one or two other drivers that can build without
> fbdev, and I guess more going forward..

It's not quite that easy since you also have to start/stop the vt
subsystem at the right point in time in your own driver. See
intel_fbdev_set_suspend. If you don't do that there's no synchronization
between fbcon shutting down/resuming and your driver, which in the best
case means fbcon does some writes to nowhere and worst case means your
chip dies (mmio to offline chip blocks) or writes go to somewhere random
in system memory (iommu contains some stale ptes since not yet fully
restored, more an issue with hibernate).

And because the console_lock is massively contended we do that in a async
worker in i915.

But anyway I agree it would still simply drivers quite a bit if we'd have
support for dummy fb helpers in the core, maybe with an explicit Kconfig.
Then drivers could switch to using that for the additional #ifdef (like
the vt stuff i915 does) and otherwise rely upon dummy static inline. That
would give us fbdev-less support for most drivers for free, which is kinda
neat.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/