linux-kernel - Re: [RESEND PATCH v2 1/2] drm/dp/mst: Reprobe EDID for MST ports on resume

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] [day] [month] [year] [list]

Date:   Mon, 26 Nov 2018 17:35:43 -0500
From:   Lyude Paul <lyude@...hat.com>
To:     "Li, Juston" <juston.li@...el.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>
Cc:     "Ciobanu, Nathan D" <nathan.d.ciobanu@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Taylor, Clinton A" <clinton.a.taylor@...el.com>,
        "jared_dominguez@...l.com" <jared_dominguez@...l.com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "mario.limonciello@...l.com" <mario.limonciello@...l.com>,
        "cpaul@...hat.com" <cpaul@...hat.com>
Subject: Re: [RESEND PATCH v2 1/2] drm/dp/mst: Reprobe EDID for MST ports on
 resume

On Mon, 2018-11-26 at 21:53 +0000, Li, Juston wrote:
> Sorry for the late reply, email got caught in a bad filter =/
> 
> I haven't been looking into it lately but we are still interested in
> getting this fixed so I can start looking into this again.
> 
> In your last email you mentioned a sysfs hotplug could be the way to
> go?
I had thought so; but I did a little more investigation and it looks like I
wasn't totally wrong when I first wrote this patch; we actually do need to
destroy the previous topology when it's not actually there and prevent the
driver from trying to set it up again. Something that apparently a simple
sysfs hotplug won't do.

I think what we might be able to do is instead of comparing against the
connector's EDID, we should try repurposing drm_dp_mst_port->cached_edid so
that it holds a copy of each mst connector's EDID instead of just logical
MSTBs, then compare against those EDIDs instead of the ones we assigned to the
drm_connector to avoid the lockdep issues that would occur from trying to grab
dev->mode_config.mutex from the suspend/resume codepaths, and decide from
where whether or not to tell the driver to cut off the topology.

Feel free to poke me about this on irc btw, might be quicker to discuss it
there
> 
> Thanks
> Juston
> 
> On Thu, 2018-11-08 at 19:43 -0500, Lyude Paul wrote:
> > Are you still looking into this at all? Even if it's not the right
> > approach
> > I'm still interested in seeing this get fixed as well/discussing what
> > I said
> > before
> > 
> > On Wed, 2018-10-24 at 22:45 +0000, Li, Juston wrote:
> > > On Wed, 2018-10-24 at 18:09 -0400, Lyude Paul wrote:
> > > > Since there's going to be quite a number of changes I need to
> > > > make to
> > > > this I'm
> > > > just going to make the changes myself! I'll make sure to Cc you
> > > > with
> > > > the
> > > > respin
> > > 
> > > Sounds good, thanks for picking it up!
> > > 
> > > Juston
> > > 
-- 
Cheers,
	Lyude Paul