Received: by 2002:a05:7208:3188:b0:7e:5202:c8b4 with SMTP id r8csp819788rbd; Fri, 23 Feb 2024 04:46:50 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVCBDhZWZwZHV+X0fh8Y52oEKvtQkp3eU5WWdgpyH2Ln956S1ztsJ7rb1heC+p7M5xF21f9/5oOagapYD1Cov+IIrAVQKZzFnG/yMK84A== X-Google-Smtp-Source: AGHT+IGPtEfh1IBtt9D5gp8VDC0oHtBkEglgN2hABHmoojE3NNlx4km68np39fgJWASoPhqDk3O/ X-Received: by 2002:a17:90a:840b:b0:29a:1192:7e6a with SMTP id j11-20020a17090a840b00b0029a11927e6amr1426287pjn.42.1708692409961; Fri, 23 Feb 2024 04:46:49 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708692409; cv=pass; d=google.com; s=arc-20160816; b=Y1KxuX4fxzNxqTA8XjfVpn6WjVK1ZoQx/fWpAknIWLFu4UTXrO6YuL+VX1N/G0U8Sd rrYPhsIK4Kuxl7NIwZ0FELBY9VE5l9jouzhYB968JP8ysSz6rjrUbVluMMAAunRtjjj5 rQR1FcRr1LgtV/z9/CCIiAVQY8NBNS49HuPLrnLns2McbT2xg7gGize27rjo3IYpO6qb jim5bhcJgCNv8PDBP/YoNRwNm3mkFz8yjsBi9QxknTX/ZK+F9tzf8l86CmFmURp3d0Kx u1BCdHDHIZXxhELTEtqJg4Lahiac/ylznHUjFLO98cqtdcGzXcI0jlaH+3tit+Y2rcyA JSiw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=1kTXhFTqC6gCFx4ZdWkowFT0qtdnA46u4M3D5HAWqM4=; fh=yLCyJoATeKAeuzHX7BdSQqrxCz9056mBMcF7HcMRTvM=; b=eKYb4k5ypyDOSK9ovJv1Gyzsaz2ebge3duXJivdKnl1SQyZKGOIrmb2ctHQdhOO1ud J+cbf53dlNj/umKMzjecD4BFGtjIaf9ZjWT9d9uoEtkUF1R6muUsZxrVfGMINgKLtj+n NpJqqmYDP0JdYaBExYpu0oZakN3amYSZ8WiC2ZR0KQKLb/BCrbk/bOsPOy2ome3/cb/s KWd61Z3NgeJe2tAJdM0ISRfRR2IQmK0yTLapqXwZLHAkgzZBdr1SgJHi37H0wYhR66sc gyPNQFUlHhNo/nSQfJejWv9ICgs8vJuK72K5Cj333jwRP6sZMICpy31FebYpO0wMI9tj UWYg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KGyzFhm7; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-78317-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-78317-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id p16-20020a17090ad31000b0029a64380aefsi1099523pju.114.2024.02.23.04.46.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Feb 2024 04:46:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-78317-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=KGyzFhm7; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-78317-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-78317-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id A9C1F2848CB for ; Fri, 23 Feb 2024 12:46:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 932DF7EEE6; Fri, 23 Feb 2024 12:46:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KGyzFhm7" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A98397E59A; Fri, 23 Feb 2024 12:46:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708692372; cv=none; b=GduW+N5EXegSiHjvx7/5I7lxs776dUv1txDubB5VY2ddSKUwZN4CUPMRv8jcvhAIcWCd6NUjIX7ZCFyNGmBkLhzfBoXQLna5RkXjKhdWZlmTZYNkF3mFostaMOvR7LyaEfZgkf8Ofbw3gLSAijC1S9IIZV+ylqGMoU9JoarJUYw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708692372; c=relaxed/simple; bh=D8T1iuzJvdgAM8BRFbh+hcm3BNH2Qr3Lwn/NyFiXNCc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZEJ5tI5Lly38Ryp0yQDc9fbPq4jpkY72WXtocF17RDOTd2GqgM+rFTqBBiXaD8uBIEvDgNM/8XbAOMxRHMma/2Mjuh4PlDCyWles+5lYTir+/A1Y74nVnSNgbfENXwsREN+cWHHJNkYZeacTC9yDuIjJ9G8XuT0FklwPmgfh0mM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KGyzFhm7; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2EAACC43330; Fri, 23 Feb 2024 12:46:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708692372; bh=D8T1iuzJvdgAM8BRFbh+hcm3BNH2Qr3Lwn/NyFiXNCc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KGyzFhm7ILcP3GXTrYTNj37Jh2zhruTwranObf38pQndYH7SSUnzadWU1wxvtVqj0 qTGEmV4Z32EIlEq08c7XGJWna2x3lkMwtjveIcgiZzFHU7xsYgbwwdTwGuHnX3OXST D1RXLNWq7+TUq2rxjavltUsvelEuCedCo/UgMgiOBANfVyo8HOL+zEYG5v9759klGd XzGpmYxdh5qbOaiVl0PTN47io8YGapFWIoQRRXww6R3c5dEImt6XFTlmI66N5sPwyv pNjksVmglMRXjR1DsnofXknnuHe1WXJvOO0RcaQUuLlURH0OKARgmF2OmmZCK5jnyA DXYjaTvKn/lDA== Received: from johan by xi.lan with local (Exim 4.97.1) (envelope-from ) id 1rdUwR-000000002kC-3nOA; Fri, 23 Feb 2024 13:46:15 +0100 Date: Fri, 23 Feb 2024 13:46:15 +0100 From: Johan Hovold To: Dmitry Baryshkov Cc: Johan Hovold , Bjorn Andersson , Andrzej Hajda , Neil Armstrong , Robert Foss , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Vinod Koul , Jonas Karlman , Laurent Pinchart , Jernej Skrabec , Konrad Dybcio , Kishon Vijay Abraham I , Rob Clark , Abhinav Kumar , Kuogee Hsieh , freedreno@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org Subject: Re: [PATCH 2/6] drm/bridge: aux-hpd: separate allocation and registration Message-ID: References: <20240217150228.5788-1-johan+linaro@kernel.org> <20240217150228.5788-3-johan+linaro@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Feb 22, 2024 at 10:57:07PM +0200, Dmitry Baryshkov wrote: > On Sat, 17 Feb 2024 at 17:03, Johan Hovold wrote: > > > > Combining allocation and registration is an anti-pattern that should be > > avoided. Add two new functions for allocating and registering an dp-hpd > > bridge with a proper 'devm' prefix so that it is clear that these are > > device managed interfaces. > > > > devm_drm_dp_hpd_bridge_alloc() > > devm_drm_dp_hpd_bridge_add() > > > > The new interface will be used to fix a use-after-free bug in the > > Qualcomm PMIC GLINK driver and may prevent similar issues from being > > introduced elsewhere. > > > > The existing drm_dp_hpd_bridge_register() is reimplemented using the > > above and left in place for now. > > > > Signed-off-by: Johan Hovold > > Reviewed-by: Dmitry Baryshkov Thanks for reviewing. > Minor nit below. > > diff --git a/include/drm/bridge/aux-bridge.h b/include/drm/bridge/aux-bridge.h > > index c4c423e97f06..4453906105ca 100644 > > --- a/include/drm/bridge/aux-bridge.h > > +++ b/include/drm/bridge/aux-bridge.h > > @@ -9,6 +9,8 @@ > > > > #include > > > > +struct auxiliary_device; > > + > > #if IS_ENABLED(CONFIG_DRM_AUX_BRIDGE) > > int drm_aux_bridge_register(struct device *parent); > > #else > > @@ -19,10 +21,23 @@ static inline int drm_aux_bridge_register(struct device *parent) > > #endif > > > > #if IS_ENABLED(CONFIG_DRM_AUX_HPD_BRIDGE) > > +struct auxiliary_device *devm_drm_dp_hpd_bridge_alloc(struct device *parent, struct device_node *np); > > +int devm_drm_dp_hpd_bridge_add(struct device *dev, struct auxiliary_device *adev); > > I had a pretty close idea during prototyping, but I ended up doing it > as a single function for the following reasons: > > First, this exports the implementation detail that internally the code > uses an aux device. That's not an issue. The opposite, with interfaces trying to do too much and hide details from the developers so that they can no longer reason about what is going on, is a real problem though. > Also, by exporting the aux device the code becomes less type-safe. By > mistake one can call devm_drm_dp_hpd_bridge_add() on any aux device, > which is not necessarily the HPD bridge. No. First, that is currently not even an issue either as the registration interface is safe to use with any aux device. Second, if you cared about about type-safety you wouldn't have used a struct device pointer for drm_aux_hpd_bridge_notify() which you back cast to an aux device. > I'd prefer to see an opaque device-specific structure instead. WDYT? That should have been there from the start. But I'm not interested in cleaning up this mess beyond what is minimally required to fix the regressions it caused. This can be reworked for 6.9 or later. > > struct device *drm_dp_hpd_bridge_register(struct device *parent, > > struct device_node *np); > > void drm_aux_hpd_bridge_notify(struct device *dev, enum drm_connector_status status); Johan