Received: by 2002:ab2:6309:0:b0:1fb:d597:ff75 with SMTP id s9csp247688lqt; Thu, 6 Jun 2024 02:20:32 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXMeT5zJBBqGHx38jouk5xURJmYq0/U4csGcDP2NYbLz47Q+A6H7McJx4mkNuYUSfq/rwBQMbUj12UC/axTbYB9vlpH1ZWTM4PEDHFuZg== X-Google-Smtp-Source: AGHT+IHsqyOI16p/DpFF0LZh5SESYR4R62uX1KNQGi6k/8NebOTeXLwVzexx+R+GQoP9ksj5rYXV X-Received: by 2002:a17:902:e5c3:b0:1f4:8363:a6fc with SMTP id d9443c01a7336-1f6a5a12867mr62570995ad.25.1717665632676; Thu, 06 Jun 2024 02:20:32 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1717665632; cv=pass; d=google.com; s=arc-20160816; b=sk3lmI18H4RtsEhGTyJbr7XR1o0PTOC3OFBuRgUwF8ysb8H478gOXr3bCSiBzUpEc6 xxIkUbAAn7FLzqCZJLLy5l/sQ5JV+C2FTzTGQ8yITCyAmFhMgiKHaLsoTZUiw0xs7/jw PLzZ2gQ41s/ipQ843ZdV120liw7ZCMakJAI8wiW8ane4YAbQMM8QFDBJWpvsZH4im09F Y3EHGVjx6iyty0GJzeKaQligfJAZ6PZaqhTb2SKdZ6FE/si3ppcbBAZ33vp/Ew6h8KD4 +JscNGYfw58Ii+URUUs0D5obrJmkDPg2DY7hUX0LOOlyU5jmuey555onIaWUENpaVV/T jwVA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:organization:references :in-reply-to:message-id:subject:cc:to:from:date; bh=FH/t6mJWS1thg/DKxOrj8mGwe1Jg6Wcelj4PDVKLCoY=; fh=tdKKOloS2lAWhGI23B4SSnOpIqNtDplyIjkeaaQgLOk=; b=ceP0TeVtDvwOX6HpyymfjJ23nTVO54uZ6I5kgyVNc/QrvbTBB1AvSjOZJJ3K6KnGZ7 6LmejeYOUsbvKwdNa41Y37jS38A1fJ+FcLyXlqDUUfpOc0qQmmUwa2e88KjjH9xCAsv5 Gj5BBPICjdsPE3wV2FurF3/4X38OOqlTh9U4sc1na9jE6rSWhAixzlDHYHnVxbdAQH/+ HAB4aGsWQqr1ZMmoqr5w1agT7wQyTx//HbCL9cN//NMgkEGKw7jRbtt4ml9sDcFU8r5N lmR2pgNdpYwityILdaHjMuDYeRSrcEhkG7N0x/5sKSJIo4+Bl8nLQS2QtafZoTOBklHM BBLw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-203970-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-203970-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id d9443c01a7336-1f6bd75fcc5si8532905ad.79.2024.06.06.02.20.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Jun 2024 02:20:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-203970-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-203970-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-203970-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com 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 446B7280C6A for ; Thu, 6 Jun 2024 09:20:32 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 371E513E3FD; Thu, 6 Jun 2024 09:18:06 +0000 (UTC) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (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 2A50519D8B5; Thu, 6 Jun 2024 09:18:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717665485; cv=none; b=V7zBnq+Cb86QUgtxQwKgId85eI1XhGJpo0v4pXXl9O2TA2+raLCuwyKDFQwPEYS9fJxBH0S1D1II9PJWLBPnEsg39cGlCYnohtF0oINOcMVITFFibjPWzQjwaXmmCt5WL8b4frfodLW37QefzP2uudklfY3SqCrYX8lg3wXUEnk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717665485; c=relaxed/simple; bh=YJdbOuaHsaurGjX4eUFukDBYK8rr97L6xCHKtPDmWFg=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=hCvjJpUpyZJ4oAUHl1mF1tlAvZo5oqOgAs84o3LKeL0qWrsv3JE2tju4J2Ez0AmThULKCEOsDoOoig72QPQpNnYPROWVHg/K0EI4V5fKaOqW4CDNQUYfLDcUuw3e2qZXbo63pqYkPPfL491dK3vvsdLKFkMWN/emKLygUMCJZbA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=Huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=Huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VvzC40f30z6K6f5; Thu, 6 Jun 2024 17:13:20 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id D1A511400E7; Thu, 6 Jun 2024 17:17:58 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 6 Jun 2024 10:17:58 +0100 Date: Thu, 6 Jun 2024 10:17:57 +0100 From: Jonathan Cameron To: Markus Elfring CC: , , "Greg Kroah-Hartman" , Heikki Krogerus , Xin Ji , LKML Subject: Re: [PATCH] usb: typec: anx7411: Use scope-based resource management in anx7411_typec_port_probe() Message-ID: <20240606101757.0000331f@Huawei.com> In-Reply-To: <889729ac-3fc5-4666-b9f5-ce6e588a341a@web.de> References: <889729ac-3fc5-4666-b9f5-ce6e588a341a@web.de> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) 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="UTF-8" Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: lhrpeml100001.china.huawei.com (7.191.160.183) To lhrpeml500005.china.huawei.com (7.191.163.240) On Wed, 5 Jun 2024 19:11:04 +0200 Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 5 Jun 2024 18:56:19 +0200 >=20 > Scope-based resource management became supported also for another > programming interface by contributions of Jonathan Cameron on 2024-02-17. > See also the commit 59ed5e2d505bf5f9b4af64d0021cd0c96aec1f7c ("device > property: Add cleanup.h based fwnode_handle_put() scope based cleanup."). >=20 > * Thus use the attribute =E2=80=9C__free(fwnode_handle)=E2=80=9D. >=20 > * Reduce the scope for the local variable =E2=80=9Cfwnode=E2=80=9D. >=20 > Fixes: fe6d8a9c8e64 ("usb: typec: anx7411: Add Analogix PD ANX7411 suppor= t") > Signed-off-by: Markus Elfring Hi Markus, Good catch. However in this case I think this is insufficient. Also your patch description should more clearly state the bug rather and impacts (a potential resource leak). I'm not 100% sure how this should work though. If the expectation is that a reference to the fwnode is held when we enter typec_register_port(), then if that errors out then we need fwnode_handle_put(). If expectation is that the reference is not held, then we should always call fwnode_handle_put() before that is called. Internally it just uses this to fill in port->dev.fwnode. Given typec_get_fw_cap() is called from there and doesn't get a reference I think expectation is that the fwnode is held by the driver calling typec_register_port() until that is unregistered. Hence should be put in the error path of that call in the calling driver. ctx->typec.port =3D typec_register_port(dev, cap); if (IS_ERR(ctx->typec.port)) { // fwnode_handle_put() in here. ret =3D PTR_ERR(ctx->typec.port); ctx->typec.port =3D NULL; dev_err(dev, "Failed to register type c port %d\n", ret); return ret; } That makes it tricky to use no_free_ptr() so I wonder if this is a case where the old fashioned fix of adding all the relevant fwnode_handle_put() calls is the better option. The __free() approach doesn't always fit. Jonathan =20 > --- > drivers/usb/typec/anx7411.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) >=20 > diff --git a/drivers/usb/typec/anx7411.c b/drivers/usb/typec/anx7411.c > index b12a07edc71b..9fb52f233a30 100644 > --- a/drivers/usb/typec/anx7411.c > +++ b/drivers/usb/typec/anx7411.c > @@ -16,6 +16,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1142,11 +1143,11 @@ static int anx7411_typec_port_probe(struct anx741= 1_data *ctx, > { > struct typec_capability *cap =3D &ctx->typec.caps; > struct typec_params *typecp =3D &ctx->typec; > - struct fwnode_handle *fwnode; > const char *buf; > int ret, i; >=20 > - fwnode =3D device_get_named_child_node(dev, "connector"); > + struct fwnode_handle *fwnode __free(fwnode_handle) > + =3D device_get_named_child_node(dev, "connector"); > if (!fwnode) > return -EINVAL; >=20 > @@ -1237,7 +1238,7 @@ static int anx7411_typec_port_probe(struct anx7411_= data *ctx, > typecp->caps_flags |=3D HAS_SINK_WATT; > } >=20 > - cap->fwnode =3D fwnode; > + cap->fwnode =3D no_free_ptr(fwnode); >=20 > ctx->typec.role_sw =3D usb_role_switch_get(dev); > if (IS_ERR(ctx->typec.role_sw)) { > -- > 2.45.1 >=20