linux-kernel - Re: [PATCH] drm/i2c: tda998x: don't register the connector

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: <20160922142429.GX1041@n2100.armlinux.org.uk>
Date:   Thu, 22 Sep 2016 15:24:29 +0100
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Brian Starkey <brian.starkey@....com>
Cc:     Daniel Vetter <daniel@...ll.ch>, Sean Paul <seanpaul@...omium.org>,
        Liviu Dudau <Liviu.Dudau@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH] drm/i2c: tda998x: don't register the connector

On Thu, Sep 22, 2016 at 02:38:45PM +0100, Brian Starkey wrote:
> However, without patching all three drivers in the same commit, there
> would always be some breakage. HDLCD and Mali-DP call
> drm_dev_register() before binding the components - this was needed to
> work with tda998x, which needed the device to be already registered
> before its bind callback runs.

I guess that is because drm_connector_register() relies on
drm_minor_register() having been previously run, which is rather
unfortunate.  That brings up the question about whether eliminating
the load callback is really such a wise move.

tda998x works fine either with or without the drm_connector_register()
call if it's bound within drm_dev_register(), which happens after the
minors have been registered.

> It's more proper to call drm_dev_register() as the very last thing
> (i.e. after component_bind_all()) to avoid races with userspace - but
> I couldn't do that without this change in tda998x first.

Actually, what you're saying is that you need to change tda998x in
lock-step with your drivers - if you have only the tda998x patch
applied, then you break.  If you apply the patch for your drivers,
you break.

That's really not good, and can be worked around by providing the
legacy ->load method, which just does the component_bind_all() call.
That makes you independent of the tda998x change, just like other
DRM drivers such as armada and tilcdc.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.