Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp515596imn; Wed, 3 Aug 2022 13:42:39 -0700 (PDT) X-Google-Smtp-Source: AA6agR7cb04qvTgP7Rc4BGZa6fLP4NDsDvDjX/3769A/igRwC3m4gCUgfDh/QK3dWHeEB9hruF40 X-Received: by 2002:a05:6402:50c9:b0:43e:42b0:f84a with SMTP id h9-20020a05640250c900b0043e42b0f84amr4438828edb.72.1659559358986; Wed, 03 Aug 2022 13:42:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659559358; cv=none; d=google.com; s=arc-20160816; b=AGR2kW5IKud9z7rdIFp/QXT7oGoq1hQ/85XPilkbuTe/fHrywt3pnuAs69c0yw/kzA ptlhwzIISwzXryg/5SgA9GxysSJ9zLnMWxT7pp1BEDUacuRnIK/Pnd8OI9/6EvVb0HMK KxAOmmahXvZdDz72HxH3FaP0gbW68St+9hxOkRU6eGbnQlCa7mhaSqZadMYbAwMqRQwp 2+cDIsk2rGhh2drF33AbOI7DWwMEIcxkTQZ2Ql6H6QE3MSGcikZ4EmwwlKImKQB8y/x6 RzcH7ZSE9zq0Y81eCSxxTbzNKla8P1Vi3bfp9pEY8l2Z9xb4fG/OQqAfTi6o8AEtOVS5 WXww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:organization:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=oVq6qfh71Z4eyfH2Jr7IUkThH+5zHyp5mI30K20IkZo=; b=f9CmK52A987+VozrxhhjYdJ+dNaYgcdx1x6tpNMBm2DXDXenrQi7TZvGZJFSuWzeF8 9lz0epjjKGg2HNpuD2FpZ9wmivwoitqbpw4jr4Gn5NoYEZepJph2eWQkh5tJCAjncNUU MTcDRZNnGNS7aNccQt3RhZa3tAHddfls+3SLxKpjef5Do9hs8nw6RAV/S8VzZSvfYMTi M5Jjdi/LBwT7bD77ZYLVY+nBY77MTaTuDImu5VFVXz8ZZbB8oFiOsN+eZ9aPdxcfx4YA OI+Cw0/hmC/uJrYMk/7wOZyOeBxLAkzYfW6GnKB2fNnT9r5VQbr9RxwVJVObsVEhEBVE sGQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RCWuYes8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mp33-20020a1709071b2100b0072a7a1bd505si16253054ejc.207.2022.08.03.13.41.47; Wed, 03 Aug 2022 13:42:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RCWuYes8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238692AbiHCU2E (ORCPT + 99 others); Wed, 3 Aug 2022 16:28:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38508 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238664AbiHCU16 (ORCPT ); Wed, 3 Aug 2022 16:27:58 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9DEA35A3FD for ; Wed, 3 Aug 2022 13:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1659558476; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oVq6qfh71Z4eyfH2Jr7IUkThH+5zHyp5mI30K20IkZo=; b=RCWuYes8YlKC3Edz4Y9HXW/tUad8qH59UFhrTvnNoAiJyZ35WEmr8z59XXedH63AMwO24t yUvFClOrNlRoievoQ2VOz9GGN0+33b1i/tH/qs6o687lQkCqaneNjRtwhWaKjAoJU5lgoc HBY3Xx6wqhXhtL5GmDXwO+l8JmmxY5Y= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-58-ZBGfC-xvPquZaeSGukkZqg-1; Wed, 03 Aug 2022 16:27:55 -0400 X-MC-Unique: ZBGfC-xvPquZaeSGukkZqg-1 Received: by mail-qk1-f199.google.com with SMTP id l15-20020a05620a28cf00b006b46997c070so14489717qkp.20 for ; Wed, 03 Aug 2022 13:27:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:user-agent:mime-version :content-transfer-encoding; bh=oVq6qfh71Z4eyfH2Jr7IUkThH+5zHyp5mI30K20IkZo=; b=Zrh6mvRa42nDn22dR+bNY2tRWmTqJylM51yoeK2seHyTwcLdu4zD0RBtRASCOxcbNl ioyfe+i0rB810kSiqDSsIrYuApvInacveXS4gZPhRcWKX9fuBddb9tfG3LINr0ECoJkS ABoi5waKEVv1gxS+gx1Y/Y0pHCr1A0LbYTcgd0yvWQR+Yt4I6KdqMkPf2AKDshIXrVIf 3mbzWwtBRfMdh26b2XjXnvOA+ylmdkalx3xnm2pzz51uatEFTEumk52LlT2ZBB4zL3WC f5acdDbty2XXJZyVU44ny69au9qIZHD4iOaXhzDVf1jHY+F9BwvrvIxiHrvJUSqj+U4t FSog== X-Gm-Message-State: AJIora8pYIb3Na36ggzGoGfTAgvdHQ7Y6/1I007/vTJ7EYUu3GwO70qi 7afYeB7heknx9XoMBbyiGQBfRmQ/SbEq7kR71XwRN9Vc8ihesylVpd/Tq1jXJyWt0yikI8yu8da osAz4bL007WXrOZHMw0I/0XRK X-Received: by 2002:a05:620a:1a20:b0:6b5:fb66:c0ed with SMTP id bk32-20020a05620a1a2000b006b5fb66c0edmr20320471qkb.582.1659558475275; Wed, 03 Aug 2022 13:27:55 -0700 (PDT) X-Received: by 2002:a05:620a:1a20:b0:6b5:fb66:c0ed with SMTP id bk32-20020a05620a1a2000b006b5fb66c0edmr20320447qkb.582.1659558474989; Wed, 03 Aug 2022 13:27:54 -0700 (PDT) Received: from [192.168.8.138] (pool-100-0-245-4.bstnma.fios.verizon.net. [100.0.245.4]) by smtp.gmail.com with ESMTPSA id r4-20020ae9d604000000b006b614fe291bsm12931459qkk.28.2022.08.03.13.27.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Aug 2022 13:27:54 -0700 (PDT) Message-ID: <848f35a693b26bfd15b3c6539eacd3e313dcd3a7.camel@redhat.com> Subject: Re: [RESEND RFC 18/18] drm/display/dp_mst: Move all payload info into the atomic state From: Lyude Paul To: "Lin, Wayne" , "dri-devel@lists.freedesktop.org" , "nouveau@lists.freedesktop.org" , "amd-gfx@lists.freedesktop.org" Cc: Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= , "Zuo, Jerry" , Jani Nikula , Imre Deak , Daniel Vetter , Sean Paul , "Wentland, Harry" , "Li, Sun peng (Leo)" , "Siqueira, Rodrigo" , "Deucher, Alexander" , "Koenig, Christian" , "Pan, Xinhui" , David Airlie , Daniel Vetter , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , Ben Skeggs , Karol Herbst , "Kazlauskas, Nicholas" , "Li, Roman" , "Shih, Jude" , Simon Ser , "Lakha, Bhawanpreet" , Mikita Lipski , Claudio Suarez , "Chen, Ian" , Colin Ian King , "Wu, Hersen" , "Liu, Wenjing" , "Lei, Jun" , "Strauss, Michael" , "Ma, Leo" , Thomas Zimmermann , =?ISO-8859-1?Q?Jos=E9?= Roberto de Souza , He Ying , Anshuman Gupta , Andi Shyti , Ashutosh Dixit , Juston Li , Sean Paul , Fernando Ramos , Luo Jiaxing , Javier Martinez Canillas , open list , "open list:INTEL DRM DRIVERS" Date: Wed, 03 Aug 2022 16:27:51 -0400 In-Reply-To: References: <20220607192933.1333228-1-lyude@redhat.com> <20220607192933.1333228-19-lyude@redhat.com> Organization: Red Hat Inc. Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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