From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 5/5] drm/doc: Use new substruct support Date: Tue, 20 Feb 2018 12:22:18 +0100 Message-ID: <20180220112218.GA9556@ulmo> References: <20180219225356.24996-1-daniel.vetter@ffwll.ch> <20180219225356.24996-5-daniel.vetter@ffwll.ch> <20180220094952.GE23425@ulmo> <20180220111035.GI22199@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0060884578==" Return-path: Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) by gabe.freedesktop.org (Postfix) with ESMTPS id 07B0B6E396 for ; Tue, 20 Feb 2018 11:22:22 +0000 (UTC) Received: by mail-qt0-x241.google.com with SMTP id f4so15859578qtj.6 for ; Tue, 20 Feb 2018 03:22:22 -0800 (PST) In-Reply-To: <20180220111035.GI22199@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: Daniel Vetter , DRI Development , Daniel Vetter List-Id: dri-devel@lists.freedesktop.org --===============0060884578== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 20, 2018 at 12:10:35PM +0100, Daniel Vetter wrote: > On Tue, Feb 20, 2018 at 10:49:52AM +0100, Thierry Reding wrote: > > On Mon, Feb 19, 2018 at 11:53:56PM +0100, Daniel Vetter wrote: > > > Note: This is untested because the new stuff hasn't landed in upstream > > > yet. But it should work. >=20 > Ok Jani put the patch into topic/core-for-CI temporarily, so I could test. > It works. >=20 > > > Signed-off-by: Daniel Vetter > > > --- > > > include/drm/drm_vblank.h | 16 ++++++++++++++++ > > > 1 file changed, 16 insertions(+) > >=20 > > I couldn't find a reference to the new stuff, so maybe this was already > > discussed, but wouldn't it be possible for the parser to figure out the > > substruct by itself? That way the event. prefix could be avoided. >=20 > https://lkml.org/lkml/2018/2/16/339 >=20 > Jon said he pulled it all in already, I guess this way was simplest, the > actual fix is a one-liner: >=20 > https://lkml.org/lkml/2018/2/16/344 >=20 > The reason for this is likely that you'll end up with name clashes > everywhere if you don't insist on the fully qualified name. Thanks for the pointers. I would've thought that the parser could simply stick the prefix onto the name itself to make it fully qualified and thereby avoid any name clashes. But looking at the patches and the parser a little, this will have to do for now: Reviewed-by: Thierry Reding --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlqMBOUACgkQ3SOs138+ s6GfoRAApJV47k4NsquP0MA0stkysXqd2zfWis1v0Me+NTyFhtuV4G4mL1GXwnN1 2dD4w1Jt+PNcrcToQU4FhrrGiVXZXcTVqcnz+Dw7ivNHfEvYjn2sjXLbot9rkWGh w59s5RhrWFnlSV+IeEXif/WnRa9KbS4Pm41DpLmr6gfKEZiEPMMlSES3WIW5NudW NtDWYRhvKBsy3Pt2/mO48o0zIQ3JPX67yTLUc+1LOY5li7+sBO8hQHgFeoZeZpLW HslcviIPis/wy3VLGm2+y0yw3bIiDVE3V7AdMUdzsjrOPItnfI6ZYRVHAVSU6Ds4 eFtTr8ZFZiFHSTdaXb0oslxuSeVMP25OtjA+tcDAK2MUflI9MlhfXDlfuPrIYd2j 4FSEfk4F6d8UC4Z5RxyXenCiNuNbY5gKJhmrnI7bmA+M6nnx4+0ZC9RdI0W75rL/ mcGeO9N7nrPIEDk9VQsp0qLn7nxlzbYnC9yNF3rTGdOXyemUTH4pIujO3mlQ1FZt rzQk6mGQdTvcIrYE8p7LmtwKLTMJigV0jRO9SQGQKaNcY7hzr2oVhceYheqGwka9 xMCN7JLoUCgfOYq7SozTvAYEfOPfzNdnP6+LQGI5cotcyCvlQyd55rc9sXHU0fWf 8EqWsmVSaZy94+HM8qO8eOuKaHI5FXPUtDuXlhtE/xsRmNUypjk= =kXSd -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- --===============0060884578== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0060884578==--