Received: by 10.223.185.116 with SMTP id b49csp307786wrg; Fri, 2 Mar 2018 19:54:40 -0800 (PST) X-Google-Smtp-Source: AG47ELvf9lz/AOsjhQ+OLmRw6ZMmwBspyev3Erm/DgWVwFNn0pRxTd5uohjPVgt0uEFxeueIxWLH X-Received: by 2002:a17:902:51ee:: with SMTP id y101-v6mr7315661plh.157.1520049280679; Fri, 02 Mar 2018 19:54:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520049280; cv=none; d=google.com; s=arc-20160816; b=K1uMeoUBAfYBGTvnfa7F6CFRNp9Z+JCczfES1+IPomT99l06SGv+PPUdaJEH+wBq7Q Rjs5eOb1DnEKLcdmlT8j+aghIdre90luNab6jEw6RcyOrzXMVR5nrIxAcQCszg98Jzb1 YAvKGgoRflTUR978HEpPyElNsMMxIJSQo3qxlkNeTbrB8IL43uPCX4twsZhoeMKXahVJ SgyGQsE4BTHcmpQLBGNmVtll/6Vap79tozNFpNfRZMdts4hgsFou4T2jCHFzASGLKK/j f4R56Xj/FMRy1SfX0KGW45A9ZBRSUf4BvN7N8Sy22GSrfzHNw7oOlyYwVPjiq0rGofWZ GTLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :references:subject:cc:to:mime-version:user-agent:from:date :message-id:arc-authentication-results; bh=GOLaxxShb0m5G8+3GEu0VtlqJ/hp0ypSl/dGGiV+9UU=; b=m35rpz8Ge6uRE8bKwBObS9UGC//TfqkIU8OH/u8cgrP0unkoGeKw5fIGjTxgGxgTom o6aEkdJr8+5MoF/+b1AVlTY/lMH1NPJR3bh6gfUi2X/ZMtkov3Xnn1fvqw1KW/95OyDh 9RnwvfrKj3k4ZSaoPSjMzqSMWxl2Em+hO8jQvi4GU8XGnH+XZoStZoTTbMmyleTQ7TQ+ Bl/WN0qUwyGkXVF+r7yWNQKDUsysE+KcvAlflXXVpaV8Db4hWrRO7Uay26cxBKeynYbJ qlOjLxmlNSUKvIS8zvEZWHKRCrCbITC4RFLpuHxEDil2ZGCwI/5E7573EeDd12dEdiv0 DqkQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o2-v6si5815863plk.457.2018.03.02.19.54.26; Fri, 02 Mar 2018 19:54:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935358AbeCCAU1 (ORCPT + 99 others); Fri, 2 Mar 2018 19:20:27 -0500 Received: from regular1.263xmail.com ([211.150.99.141]:56717 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932890AbeCCAUZ (ORCPT ); Fri, 2 Mar 2018 19:20:25 -0500 Received: from jeffy.chen?rock-chips.com (unknown [192.168.167.12]) by regular1.263xmail.com (Postfix) with ESMTP id E0A4A5E; Sat, 3 Mar 2018 08:20:19 +0800 (CST) X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 Received: from [172.16.22.73] (localhost [127.0.0.1]) by smtp.263.net (Postfix) with ESMTPA id 47944360; Sat, 3 Mar 2018 08:20:09 +0800 (CST) X-RL-SENDER: jeffy.chen@rock-chips.com X-FST-TO: laurent.pinchart@ideasonboard.com X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: jeffy.chen@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-SENDER: cjf@rock-chips.com X-DNS-TYPE: 0 Received: from [172.16.22.73] (unknown [103.29.142.67]) by smtp.263.net (Postfix) whith ESMTP id 5024YA2J20; Sat, 03 Mar 2018 08:20:15 +0800 (CST) Message-ID: <5A99EA37.6070006@rock-chips.com> Date: Sat, 03 Mar 2018 08:20:07 +0800 From: JeffyChen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20130126 Thunderbird/19.0 MIME-Version: 1.0 To: Laurent Pinchart , Enric Balletbo i Serra CC: Sandy Huang , =?UTF-8?B?SGVpa28gU3TDvGJuZXI=?= , Andrzej Hajda , linux-rockchip@lists.infradead.org, Archit Taneja , linux-kernel@vger.kernel.org, Russell King , Neil Armstrong , dri-devel@lists.freedesktop.org, Jose Abreu , Hans Verkuil , Jernej Skrabec , linux-arm-kernel@lists.infradead.org, David Airlie , kernel@collabora.com, Daniel Vetter , Sean Paul Subject: Re: [PATCH v9 5/5] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach References: <20180302175757.28192-1-enric.balletbo@collabora.com> <20180302175757.28192-6-enric.balletbo@collabora.com> <2714218.VptbnhJPkd@avalon> In-Reply-To: <2714218.VptbnhJPkd@avalon> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Laurent, On 03/03/2018 05:49 AM, Laurent Pinchart wrote: > Hi Enric, > > Thank you for the patch. > > On Friday, 2 March 2018 19:57:57 EET Enric Balletbo i Serra wrote: >> From: Jeffy Chen >> >> We inited connector in attach(), so need a detach() to cleanup. > > Do we ? The dw-hdmi driver already sets drm_connector_cleanup() as the > connector .destroy() handler, and the .destroy() operation is called by the > DRM core. None of the other bridge drivers call drm_connector_cleanup() > directly. hmmm, checking the code, there are also lots of drivers do the cleanup(drm_connector_cleanup or funcs->destroy): drm# grep -r "connector.*funcs->destroy" . ./rockchip/inno_hdmi.c: hdmi->connector.funcs->destroy(&hdmi->connector); ./rockchip/cdn-dp-core.c: connector->funcs->destroy(connector); ./bridge/analogix/analogix_dp_core.c: dp->connector.funcs->destroy(&dp->connector); ./msm/hdmi/hdmi.c: hdmi->connector->funcs->destroy(hdmi->connector); ./msm/dsi/dsi.c: msm_dsi->connector->funcs->destroy(msm_dsi->connector); ./msm/edp/edp.c: edp->connector->funcs->destroy(edp->connector); ./zte/zx_hdmi.c: hdmi->connector.funcs->destroy(&hdmi->connector); ./drm_connector.c: connector->funcs->destroy(connector); ./drm_connector.c: connector->funcs->destroy(connector); ./nouveau/dispnv04/disp.c: connector->funcs->destroy(connector); ./nouveau/nv50_display.c: mstc->connector.funcs->destroy(&mstc->connector); ./nouveau/nv50_display.c: connector->funcs->destroy(connector); when i debug analogix_dp bind/unbind, i found that we need to cleanup the connector(reported by kmemleak). so i added it to ./bridge/analogix/analogix_dp_core.c...after that i saw dw-hdmi missing that too(by checking the code), so make this patch. but i didn't really tested it on devices using dw-hdmi, so i'm not very sure the dw-hdmi(maybe also other bridges) is the same with analogix_dp. i can try to find a chromebook veyron to check it next week :) but even there's a leak, i'm still not very sure about: should the caller of drm_connector_init cleanup it or the caller of drm_bridge_attach should do it(for example analogix_dp_bind/analogix_dp_unbind) or should the DRM core take care of that? > >> Signed-off-by: Jeffy Chen >> Signed-off-by: Thierry Escande >> Signed-off-by: Enric Balletbo i Serra >> --- >> >> Changes in v9: None >> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index >> f9802399cc0d..5626922f95f9 100644 >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> @@ -1985,6 +1985,13 @@ static int dw_hdmi_bridge_attach(struct drm_bridge >> *bridge) return 0; >> } >> >> +static void dw_hdmi_bridge_detach(struct drm_bridge *bridge) >> +{ >> + struct dw_hdmi *hdmi = bridge->driver_private; >> + >> + drm_connector_cleanup(&hdmi->connector); >> +} >> + >> static enum drm_mode_status >> dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge, >> const struct drm_display_mode *mode) >> @@ -2041,6 +2048,7 @@ static void dw_hdmi_bridge_enable(struct drm_bridge >> *bridge) >> >> static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = { >> .attach = dw_hdmi_bridge_attach, >> + .detach = dw_hdmi_bridge_detach, >> .enable = dw_hdmi_bridge_enable, >> .disable = dw_hdmi_bridge_disable, >> .mode_set = dw_hdmi_bridge_mode_set, >