linux-kernel - Re: [PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

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:	Wed, 15 Jun 2016 21:29:38 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Liviu Dudau <Liviu.Dudau@....com>
Cc:	David Airlie <airlied@...ux.ie>, Rob Herring <robh+dt@...nel.org>,
	Brian Starkey <brian.starkey@....com>,
	Emil Velikov <emil.l.velikov@...il.com>,
	devicetree <devicetree@...r.kernel.org>,
	DRI devel <dri-devel@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>,
	David Brown <David.Brown@....com>,
	LAKML <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

On Wed, Jun 15, 2016 at 7:21 PM, Liviu Dudau <Liviu.Dudau@....com> wrote:
> On Wed, Jun 15, 2016 at 07:13:15PM +0200, Daniel Vetter wrote:
>> On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau <Liviu.Dudau@....com> wrote:
>> > On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote:
>> >> On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu Dudau wrote:
>> >> > Add support for the new family of Display Processors from ARM Ltd.
>> >> > This commit adds basic support for Mali DP500, DP550 and DP650
>> >> > parts, with only the display engine being supported at the moment.
>> >> >
>> >> > Cc: David Brown <David.Brown@....com>
>> >> > Cc: Brian Starkey <Brian.Starkey@....com>
>> >> >
>> >> > Signed-off-by: Liviu Dudau <Liviu.Dudau@....com>
>> >>
>> >> Small thing I noticed: drm_dev_register/connector_register_all should be
>> >> the last step in your init code, and unregister the first. Atm it's
>> >> somewhere in the middle. But perfectly fine to do that as a follow-up.
>> >
>> > I've tried that, but the connector and encoder that gets registered as part
>> > of the component_bind_all() fails if there is no drm dev registered. You did
>> > comment on the v4 version about that and I did test your idea, sorry for
>> > forgeting to update you on that.
>>
>> Why does it fail? That shouldn't happen ... we need to be able to set
>> up everything first, before we register.
>
> Could be the tda998x_drv fault, but I'm getting this splat:

Yeah, tda9998x needs to be fixed to _not_ register it's connector
before the overall (componentized) driver is ready. We need to make
sure first ofc that all users of that driver do register connectors,
but Chris' patch series will take care of that. But tda9998x needs to
be fixed either way.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch