From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 066DC30F924 for ; Tue, 10 Feb 2026 20:30:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770755425; cv=none; b=u+34Tx8FKY9uBGUio+HtSKYiheEDrEO+eUENlX66CcnjSsrRUZw/QWenGhkeOUjPLWyHEEyxy/ADner+fdDhhGssPzCmYP43LIQOWyp3Ronvq6lob5rJHAms+EHor3eOsCjLkkVvljhVXyLTgTdtuVqLHXsZACBI/z1RIDvPWAU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770755425; c=relaxed/simple; bh=ozX0DfJbianv8YgUAQs0yzmd6i0/RwkwlfCdbQ/sKBA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=n16i4ERnf7+9/7tdUpqH3duL41thVdKI/jKyPTTyePTony003eS/Wka1KhuTysyzCUF2AgzeAjeJqDdt6zB0YtKp6T6dliCYHnB/4D5K8G+oUVpKTwM5C27o3BPpkjKvRa6T2DtqdhltgA4NeRFLObBCp5jF9k9hmG0vUAJSp1s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=NwvFoiW7; arc=none smtp.client-ip=209.85.221.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NwvFoiW7" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-43636c9fd7eso233700f8f.0 for ; Tue, 10 Feb 2026 12:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770755422; x=1771360222; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=PmFqy4a/y7/G6LMLBYsR10AC71ubgLHhE6Tq452T3aA=; b=NwvFoiW7x1Zf1akpVSy9MzlIUhINNFVUmmkrl17Rkqopo/IVxvePvpiK3Gyeqapr+u f5Qd8Fa5Q3Dna34DMYDpR87CKJV5CTVcGremNwTQDtuQAoiCxjK+Wdh9LRVawr2j+AoS i9SnwQr2nNk01CGcefd0Krgbrbq/PptW3M/ijOiE6IIK8pbvBRY2iPWZqhA0ZGwDdf71 dwc8AL48RCyMiUxKEfIZckOwR+fCgP08zk/S3hyevG0IhWWMTT7WltblwI6IQPgwUl/0 Jd7+4MhoXn9xOhCcpc2Bev0MKB1EIA5qoIT234iD+s+xNq6x2vOXfSgcSQziqhlXBWGT ds0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770755422; x=1771360222; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PmFqy4a/y7/G6LMLBYsR10AC71ubgLHhE6Tq452T3aA=; b=NsojcDr3+ffTDQry1ziKWZytRLUR/9MwNdSTHDSRE946A8Mj2feUsVHU4GH8f4i7i9 3C3tkXrttIkXfOr6pg/m6mjNh+YtfCGk3ZHTyI2AmsQKuvzaQbjbpO4JvmIH9FSxKGlS /S4YVboesIOvd9leMm16v2OgsWaFqFMmF3F6S5nSuXIgSCcM2DJYQjG+Ccrnp8j97GCH l4I/RB5xa2pTZqB011ZX135BSKHRALWjO6WULW1jioyq1coSC+vQagTLT2RTyuDKcLZE 9EOrnFYUKVL6dcWQDuX2hzNvZ9nFMcz9VPmzanX8k4hsCnB+6ueJAnKCwmNbxYt+3eC0 Tifg== X-Forwarded-Encrypted: i=1; AJvYcCUPiuZIOouluoL9QxCW734GG2+an4CnH347IkZH9czbuVDXlGjoKPVbokxaguG/iVBjKxwCs+zP0NMfMX4=@vger.kernel.org X-Gm-Message-State: AOJu0YxtdvkVOEUVjdpr9bVu4+KJ1FXkK9MvpR8eIlqKwsvKt6947qGY LivGb3+Vp5HhXr9QNdKURWmr1rS3PzSHVVCQOV0cgyHdxdty9fhQuHmy X-Gm-Gg: AZuq6aJ+TYetvpYe8C44iAzTIuz49gVDwPFMGzASoZnauQxXvm9DiMkmd029IPhsMig KOAOEnjRuyoL0UwXa6l6wt/1DKwfOFtwbpPZAV25iVaRvIbhlpDDuWdTnoGagSdDhqfs9bW/w2n C/pbdYkYhZDJPDFnD7z5VUPVDmm1b/T+nKVHw41fMNNAWkgovDS5gSqnhjwpLeQVPqlXbdQKUr8 c7qB8lLglawnSX3Q96F1N27WVULx3sgHFOQttrbnjIMS1U+yZWBybNqlanIxnkbNwp8l/mBWn9N n59lAgXPxHPlZ4Ohwx5fzyDjuEQrcoSkB4tynPw5DfNsbEwzGKLuCOI0/JbBkeVKKG8NGAc00lb AuE2tH3WxHNzoxEFnN/ZQPXIiOJxgIIdFIAXEZtyZEv/d/c4+ZEhg0wjsS9rWjPN6lHjdpEMApJ TP3wLqqGe7wIX717g= X-Received: by 2002:a05:600c:1f82:b0:477:7a78:3000 with SMTP id 5b1f17b1804b1-48351228e20mr24402285e9.6.1770755422195; Tue, 10 Feb 2026 12:30:22 -0800 (PST) Received: from skbuf ([2a02:2f04:d501:d900:d8ac:c964:9b43:1b13]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4835a5c0df8sm3313025e9.0.2026.02.10.12.30.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Feb 2026 12:30:20 -0800 (PST) Date: Tue, 10 Feb 2026 22:30:18 +0200 From: Vladimir Oltean To: Felix Gu Cc: Vinod Koul , Neil Armstrong , Kishon Vijay Abraham I , Jyri Sarha , linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] phy: ti: j721e-wiz: Fix device_node leak in wiz_get_lane_phy_types() Message-ID: <20260210203018.dr6dwj55aob3phsd@skbuf> References: <20260211-wiz-v1-1-fdd018d02f33@gmail.com> <20260211-wiz-v1-1-fdd018d02f33@gmail.com> 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: <20260211-wiz-v1-1-fdd018d02f33@gmail.com> <20260211-wiz-v1-1-fdd018d02f33@gmail.com> Hi Felix, On Wed, Feb 11, 2026 at 02:14:11AM +0800, Felix Gu wrote: > The 'serdes' device_node is obtained using of_get_child_by_name(), > which increments the reference count. However, it is never put, > leading to a memory leak. > > Use the __free(device_node) attribute to automatically decrement > the reference count when the 'serdes' variable goes out of scope. > > Fixes: 7ae14cf581f2 ("phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver") > Signed-off-by: Felix Gu > --- > drivers/phy/ti/phy-j721e-wiz.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c > index 12a19bf2875c..904541e9138e 100644 > --- a/drivers/phy/ti/phy-j721e-wiz.c > +++ b/drivers/phy/ti/phy-j721e-wiz.c > @@ -1407,9 +1407,8 @@ MODULE_DEVICE_TABLE(of, wiz_id_table); > > static int wiz_get_lane_phy_types(struct device *dev, struct wiz *wiz) > { > - struct device_node *serdes; > - > - serdes = of_get_child_by_name(dev->of_node, "serdes"); > + struct device_node *serdes __free(device_node) = > + of_get_child_by_name(dev->of_node, "serdes"); > if (!serdes) { > dev_err(dev, "%s: Getting \"serdes\"-node failed\n", __func__); > return -EINVAL; > > --- > base-commit: 193579fe01389bc21aff0051d13f24e8ea95b47d > change-id: 20260204-wiz-9a67604a034f > > Best regards, > -- > Felix Gu > > You are fixing a bug from 2020 (v5.8) with functionality introduced in 2023, creating avoidable headache for backporters (the oldest supported LTS is 5.10, where the cleanup API does not exist). Could we reimplement this the "normal" of_node_put() way? I realize this is not netdev, but this piece of advice from Documentation/process/maintainer-netdev.rst regarding use in drivers seems common sense and relevant here: Low level cleanup constructs (such as ``__free()``) can be used when building APIs and helpers, especially scoped iterators. However, direct use of ``__free()`` within networking core and drivers is discouraged. Similar guidance applies to declaring variables mid-function.