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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161115094631.GA6680@n2100.armlinux.org.uk>
Date:   Tue, 15 Nov 2016 09:46:31 +0000
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Daniel Vetter <daniel@...ll.ch>, David Airlie <airlied@...ux.ie>
Cc:     Brian Starkey <brian.starkey@....com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [GIT PULL] Re: [PATCH] drm: tda998x: mali-dp: hdlcd: refactor
 connector registration

I guess Dave must have missed this as I can't see it in drm-next, so
I'm resending the pull request.

On Tue, Nov 08, 2016 at 10:59:43AM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 10:25:52AM +0100, Daniel Vetter wrote:
> > Hm, I entirely missed that part of the troubles. Anyway, if you all agree
> > on a patch I certainly won't block it, feel free to merge through suitable
> > trees (or I can smash it into drm-misc if that's wanted).
> 
> I think those who are interested in seeing the drm_connector_register()
> call disappear from tda998x only care about that happening, but not how
> it happens.
> 
> We have agreement between myself, Brian and Liviu on this approach, and
> I think everyone else is waiting for me to push out the commit so it can
> be used as the basis for their work.  I think everyone else is waiting
> for me to push something out which gets us past this log-jam.
> 
> I don't understand the connectivity between drm-misc and David's drm
> tree - so I'm going to let you make the decision on whether to merge
> this into drm-misc.  I normally send my pull requests for Armada and
> TDA998x changes to David, which means when I send my other TDA998x
> changes, the mali/tda998x commit will be included in that pull
> request too.  So I'm wondering whether it would make more sense for
> me to send it to David instead, or whether I need to send my other
> changes through drm-misc instead.  I find the whole drm vs drm-misc
> thing rather confusing.
> 
> I think we should get this accepted into drm trees before anyone bases
> their work on this commit (which is why I've been holding off during
> the last week, waiting for DRM folk to get back from Santa Fe and
> readjust to the higher atmospheric pressure!)
> 
> Anyway, here is my pull request for the mali/hdlcd/tda998x commit which
> I'd normally send to David - I don't mind which tree it goes into as
> long as things work out nicely.
> 
> 8<===
> 
> David,
> 
> Please incorporate the latest TDA998x I2C driver (drm-tda998x-mali
> branch), which can be found at:
> 
>   git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-mali
> 
> with SHA1 90731c24d2db7ec04df43ddbcee9605183d05187.
> 
> This change removes the call to drm_connector_register() which has been
> blocking the proper de-midlayer conversion of other DRM drivers.
> Unfortunately, hdlcd and mali have intimate dependencies on this change,
> which is why these drivers need to be fixed up in the same commit - they
> can't be separate commits without these drivers breaking.  All other
> DRM drivers which make use of tda998x (to my knowledge - armada, tilcdc)
> cope with this change.
> 
> This will update the following files:
> 
>  drivers/gpu/drm/arm/hdlcd_drv.c   | 19 +++++++++++--------
>  drivers/gpu/drm/arm/malidp_drv.c  | 18 +++++++++++-------
>  drivers/gpu/drm/i2c/tda998x_drv.c |  8 --------
>  3 files changed, 22 insertions(+), 23 deletions(-)
> 
> through these changes:
> 
> Brian Starkey (1):
>       drm/i2c: tda998x: mali-dp: hdlcd: refactor connector registration
> 
> Many thanks.
> 
> -- 
> 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.

-- 
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ