| 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
| ||
|
Date: Mon, 08 Aug 2022 18:53:13 -0400
From: Lyude Paul <lyude@...hat.com>
To: "Lin, Wayne" <Wayne.Lin@....com>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>,
"amd-gfx@...ts.freedesktop.org" <amd-gfx@...ts.freedesktop.org>
Cc: Ville Syrjälä
<ville.syrjala@...ux.intel.com>, "Zuo, Jerry" <Jerry.Zuo@....com>,
Jani Nikula <jani.nikula@...el.com>,
Imre Deak <imre.deak@...el.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Sean Paul <sean@...rly.run>,
"Wentland, Harry" <Harry.Wentland@....com>,
"Li, Sun peng (Leo)" <Sunpeng.Li@....com>,
"Siqueira, Rodrigo" <Rodrigo.Siqueira@....com>,
"Deucher, Alexander" <Alexander.Deucher@....com>,
"Koenig, Christian" <Christian.Koenig@....com>,
"Pan, Xinhui" <Xinhui.Pan@....com>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
Ben Skeggs <bskeggs@...hat.com>,
Karol Herbst <kherbst@...hat.com>,
"Kazlauskas, Nicholas" <Nicholas.Kazlauskas@....com>,
"Li, Roman" <Roman.Li@....com>, "Shih, Jude" <Jude.Shih@....com>,
Simon Ser <contact@...rsion.fr>,
"Lakha, Bhawanpreet" <Bhawanpreet.Lakha@....com>,
Mikita Lipski <mikita.lipski@....com>,
Claudio Suarez <cssk@...-c.es>, "Chen, Ian" <Ian.Chen@....com>,
Colin Ian King <colin.king@...el.com>,
"Wu, Hersen" <hersenxs.wu@....com>,
"Liu, Wenjing" <Wenjing.Liu@....com>, "Lei, Jun" <Jun.Lei@....com>,
"Strauss, Michael" <Michael.Strauss@....com>,
"Ma, Leo" <Hanghong.Ma@....com>,
Thomas Zimmermann <tzimmermann@...e.de>,
José Roberto de Souza
<jose.souza@...el.com>, He Ying <heying24@...wei.com>,
Anshuman Gupta <anshuman.gupta@...el.com>,
Andi Shyti <andi.shyti@...ux.intel.com>,
Ashutosh Dixit <ashutosh.dixit@...el.com>,
Juston Li <juston.li@...el.com>,
Sean Paul <seanpaul@...omium.org>,
Fernando Ramos <greenfoo@....eu>,
Luo Jiaxing <luojiaxing@...wei.com>,
Javier Martinez Canillas <javierm@...hat.com>,
open list <linux-kernel@...r.kernel.org>,
"open list:INTEL DRM DRIVERS" <intel-gfx@...ts.freedesktop.org>
Subject: Re: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info
into the atomic state
On Mon, 2022-08-08 at 10:02 +0000, Lin, Wayne wrote:
> [Public]
>
>
>
> > -----Original Message-----
> > From: Lyude Paul <lyude@...hat.com>
> > Sent: Thursday, August 4, 2022 4:28 AM
> > To: Lin, Wayne <Wayne.Lin@....com>; dri-devel@...ts.freedesktop.org;
> > nouveau@...ts.freedesktop.org; amd-gfx@...ts.freedesktop.org
> > Cc: Ville Syrjälä <ville.syrjala@...ux.intel.com>; Zuo, Jerry
> > <Jerry.Zuo@....com>; Jani Nikula <jani.nikula@...el.com>; Imre Deak
> > <imre.deak@...el.com>; Daniel Vetter <daniel.vetter@...ll.ch>; Sean Paul
> > <sean@...rly.run>; Wentland, Harry <Harry.Wentland@....com>; Li, Sun
> > peng (Leo) <Sunpeng.Li@....com>; Siqueira, Rodrigo
> > <Rodrigo.Siqueira@....com>; Deucher, Alexander
> > <Alexander.Deucher@....com>; Koenig, Christian
> > <Christian.Koenig@....com>; Pan, Xinhui <Xinhui.Pan@....com>; David
> > Airlie <airlied@...ux.ie>; Daniel Vetter <daniel@...ll.ch>; Jani Nikula
> > <jani.nikula@...ux.intel.com>; Joonas Lahtinen
> > <joonas.lahtinen@...ux.intel.com>; Rodrigo Vivi <rodrigo.vivi@...el.com>;
> > Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>; Ben Skeggs
> > <bskeggs@...hat.com>; Karol Herbst <kherbst@...hat.com>; Kazlauskas,
> > Nicholas <Nicholas.Kazlauskas@....com>; Li, Roman
> > <Roman.Li@....com>; Shih, Jude <Jude.Shih@....com>; Simon Ser
> > <contact@...rsion.fr>; Lakha, Bhawanpreet
> > <Bhawanpreet.Lakha@....com>; Mikita Lipski <mikita.lipski@....com>;
> > Claudio Suarez <cssk@...-c.es>; Chen, Ian <Ian.Chen@....com>; Colin Ian
> > King <colin.king@...el.com>; Wu, Hersen <hersenxs.wu@....com>; Liu,
> > Wenjing <Wenjing.Liu@....com>; Lei, Jun <Jun.Lei@....com>; Strauss,
> > Michael <Michael.Strauss@....com>; Ma, Leo <Hanghong.Ma@....com>;
> > Thomas Zimmermann <tzimmermann@...e.de>; José Roberto de Souza
> > <jose.souza@...el.com>; He Ying <heying24@...wei.com>; Anshuman
> > Gupta <anshuman.gupta@...el.com>; Andi Shyti
> > <andi.shyti@...ux.intel.com>; Ashutosh Dixit <ashutosh.dixit@...el.com>;
> > Juston Li <juston.li@...el.com>; Sean Paul <seanpaul@...omium.org>;
> > Fernando Ramos <greenfoo@....eu>; Luo Jiaxing
> > <luojiaxing@...wei.com>; Javier Martinez Canillas <javierm@...hat.com>;
> > open list <linux-kernel@...r.kernel.org>; open list:INTEL DRM DRIVERS
> > <intel-gfx@...ts.freedesktop.org>
> > Subject: Re: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info
> > into the atomic state
> >
> > On Tue, 2022-07-05 at 09:10 +0000, Lin, Wayne wrote:
> > > > +struct drm_dp_mst_port;
> > > > +
> > > > /* DP MST stream allocation (payload bandwidth number) */
> > > > struct dc_dp_mst_stream_allocation {
> > > > uint8_t vcp_id;
> > > > /* number of slots required for the DP stream in
> > > > * transport packet */
> > > > uint8_t slot_count;
> > > > + /* The MST port this is on, this is used to associate DC MST
> > > > + payloads
> > > > with their
> > > > + * respective DRM payloads allocations, and can be ignored on non-
> > > > Linux.
> > > > + */
> > >
> > > Is it necessary for adding this new member? Since this is for setting
> > > the DC HW and not relating to drm.
> >
> > I don't entirely know, honestly. The reasons I did it:
> >
> > * Mapping things from DRM to DC and from DC to DRM is really confusing for
> > outside contributors like myself, so it wasn't even really clear to me if
> > there was another way to reconstruct the DRM context from the spots
> > where
> > we call from DC up to DM (not a typo, see next point).
> > * These DC structs for MST are already layer mixing as far as I can tell,
> > just not in an immediately obvious way. While this struct itself is for DC,
> > there's multiple spots where we pass the DC payload structs down from
> > DM to
> > DC, then pass them back up from DC to DM and have to figure out how to
> > reconstruct the DRM context that we actually need to use the MST helpers
> > from that. So, that kind of further complicates the confusion of where
> > layers should be separated.
> > * As far as I'm aware with C there shouldn't be any issue with adding a
> > pointer to a struct whose contents are undefined. IMHO, this is also
> > preferable to just using void* because then at least you get some hint as
> > to the actual type of the data and avoid the possibility of casting it to
> > the wrong type. So tl;dr, on any platform even outside of Linux with a
> > reasonably compliant compiler this should still build just fine. It'll even
> > give you the added bonus of warning people if they try to access the
> > contents of this member in DC on non-Linux platforms. If void* is preferred
> > though I'm fine with switching it to that.
> >
> > --
> > Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
>
> Hi Lyude,
>
> Thanks for your time!
> I was thinking that our DC just mainly takes care of HW related programming.
> Struct dc_dp_mst_stream_allocation is only used to construct a copy of the virtual
> channel payload ID and slots count of payload allocation table determined by
> dm/drm. ID and slots are only things required for programming HW registers.
> I think there shouldn't be any spots to try to construct the DRM context from
> this dc struct since there is no such concept in HW level. Our HW should only
> take care of local DP link and it doesn't have overall topology info.
Looking at the code I wrote again and realizing I slightly misspoke, looking
at the code again I think I probably can drop this. It's likely I just got
totally lost with the DC codebase and thought this was necessary when it
wasn't. Will drop in the respin
>
> Thanks!
>
> Regards,
> Wayne
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Powered by blists - more mailing lists