Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp3514994imb; Tue, 5 Mar 2019 11:19:21 -0800 (PST) X-Google-Smtp-Source: APXvYqy3lYIDjXxm9E5FmQ0Z8H3PAu5cxfT7Kd7UkchdRXfXbHX7XWW1aBssSBalav9HwOZrdiYg X-Received: by 2002:a63:d158:: with SMTP id c24mr2768786pgj.34.1551813561760; Tue, 05 Mar 2019 11:19:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551813561; cv=none; d=google.com; s=arc-20160816; b=n4xGAPGt9OQOVLaLUzOcG5dT3W4ohJDydhPhlCdUntKW/G7s8j6i4L+FOjk3qzR94E BRF1XtdobZGSy+LCeEKNMNz3O3ADUY4Cv7jZfbHFTRKNy1IQAsP3xr09xEI2phtT/ZYr 0ov9F1T7dFyZZQAPRhSDZymBQDBmjAGznyybias00CCP3/RmurMltWSI3NAnV/3lOH/B y9EDhU2UUu/Bz7D68iLquTPNrWC3AzXy/YibbKkK1gfmUqRZg+HXMHKkoqEgg3NxSdJD /vawTVseKpLbR8qtG5neEEQYSZuRkHbjzk4HzAPBeXm529a21nu8HDQHraxEuv+W4yJn Q0gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=fL+TKYligpedsr6yGW7admNa5ubTDeYOjHMXRI35U3I=; b=G5bXryfbI6Z8jgLbK21DSWy6uwkezCjSqoNEuLSiXTzj/amMl+pqYynbMdSqD3n8ew 8lVy4d4rRCCBXXNijiCPePz26Kr1DbEEqhtMrXKa03hxQAV+lrNykaPg8N0PmuO6Daiq kTZMPYE1x11OOe6DGTSpcoWcI3CyM22TYwgcVoLyOlQvTe/XyWOLb9d5BaEiYgyw/htQ 90wEqTsdiF/aLReKUmXi1exeS1WTwBNavPNKOenRcGG3lBDsb8SUaHJEINO+CdpbszNJ 65T4YBC3oCIx6Jrkyp4waVEHS/wrLgmBqBqrC9eso7aHxR+YzYJ/EnHgYRQjsDctMWFX 6PGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ohQr+Bxe; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w3si9024141pll.417.2019.03.05.11.19.06; Tue, 05 Mar 2019 11:19:21 -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; dkim=pass header.i=@chromium.org header.s=google header.b=ohQr+Bxe; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728214AbfCETEa (ORCPT + 99 others); Tue, 5 Mar 2019 14:04:30 -0500 Received: from mail-lj1-f194.google.com ([209.85.208.194]:42914 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727815AbfCETE3 (ORCPT ); Tue, 5 Mar 2019 14:04:29 -0500 Received: by mail-lj1-f194.google.com with SMTP id d14so8576491ljl.9 for ; Tue, 05 Mar 2019 11:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fL+TKYligpedsr6yGW7admNa5ubTDeYOjHMXRI35U3I=; b=ohQr+BxeQg1+LF6sZhHrM+Mt1kdjBZHmM4qKZ+yYqe4oByz42NT0LBeCh1Y5Z5MhMM 8q1s/p1fqhu4TGy05fCGxlxPbn6pk/yQv4BQaKWKTMOhT3UYZ76jofNzlKR1SS6nEGSx mRS3hPZ+TT6TsYjWIfw8GAZbyxsG67UUJDTLA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fL+TKYligpedsr6yGW7admNa5ubTDeYOjHMXRI35U3I=; b=WB3sCsJrCZIcKnql6XQIOHXTe4OISPNIZqsq6xNVtSGeij/wsVwCyjjodmMp+k3r1F kFfJoCDePMy8gmeROI2fl5xlg541oZVK2/BVHdphVaC5RABsoE2wN3cA+xC81WbW9Rqr jCWXsHZTBHxd8cxXGnwAQmyNAVsrYZNSR0TeaVOaYg01SwmCMxuT/mvMO4XkCvr4KyM5 hillL0nOwYuHtvt6GEUhS8NlFYdALHVs8kNfI8vK5NvW+GjXSwpYIDVmr2WW42CnR/PU BYJECirDdTA7XtLXh4CIMTn9vOlFwf7tqYvCow2vh8dJwKSoDH/WcE410QmDkX0hNNrW H/Dw== X-Gm-Message-State: APjAAAWNcTnE3zqAPWUzL2qWCAja4tLCu1Ran4ranFhAmm4u53DpJLhD NYOQg8xaxCdqja8bGeYPL8WPHJMydKk= X-Received: by 2002:a2e:8886:: with SMTP id k6mr95519lji.43.1551812666521; Tue, 05 Mar 2019 11:04:26 -0800 (PST) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id c190sm2329041lfg.84.2019.03.05.11.04.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 11:04:26 -0800 (PST) Received: by mail-lf1-f47.google.com with SMTP id h6so2759355lfc.2 for ; Tue, 05 Mar 2019 11:04:25 -0800 (PST) X-Received: by 2002:a19:a417:: with SMTP id q23mr1716948lfc.27.1551812665056; Tue, 05 Mar 2019 11:04:25 -0800 (PST) MIME-Version: 1.0 References: <1546318276-18993-1-git-send-email-yong.wu@mediatek.com> <1546318276-18993-3-git-send-email-yong.wu@mediatek.com> <1551278000.17917.50.camel@mhfsdcap03> In-Reply-To: <1551278000.17917.50.camel@mhfsdcap03> From: Evan Green Date: Tue, 5 Mar 2019 11:03:49 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 02/13] driver core: Remove the link if there is no driver with AUTO flag To: Yong Wu Cc: Joerg Roedel , Greg Kroah-Hartman , Matthias Brugger , Rob Herring , Robin Murphy , Tomasz Figa , Will Deacon , linux-mediatek@lists.infradead.org, srv_heupstream@mediatek.com, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML , linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, Arnd Bergmann , yingjoe.chen@mediatek.com, youlin.pei@mediatek.com, Nicolas Boichat Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 27, 2019 at 6:33 AM Yong Wu wrote: > > On Mon, 2019-02-25 at 15:53 -0800, Evan Green wrote: > > On Mon, Dec 31, 2018 at 8:52 PM Yong Wu wrote: > > > > > > DL_FLAG_AUTOREMOVE_CONSUMER/SUPPLIER means "Remove the link > > > automatically on consumer/supplier driver unbind", that means we should > > > remove whole the device_link when there is no this driver no matter what > > > the ref_count of the link is. > > > > > > CC: Greg Kroah-Hartman > > > Signed-off-by: Yong Wu > > > --- > > > The ref_count of our device_link normally is over 1. When the consumer > > > device driver is removed, whole the device_link should be removed. > > > Thus, I add this patch. > > > --- > > > > I will admit to reading about device links for the first time while > > reviewing this patch, but I don't really get this. Why use a kref at > > all if we're just going to ignore its value? For instance, I see that > > if you call device_link_add() with the same supplier and consumer, it > > uses the kref to return the same link. That machinery is broken with > > your change. Although I don't see any uses of it, you might also > > expect a supplier or consumer could do a kref_get() on the link it got > > back from device_link_add(), and have a reasonable expectation that > > the link wouldn't be freed out from under it. This would also be > > broken. > > > > Can you explain why your device_links normally have a reference count > > >1, > > I use device link between the smi-larb device and the iommu-consumer > device. Take a example, smi-larb1 have 4 VDEC ports. From 4/13 in this > patchset, we use device_link to link the VDEC device and the smi-larb1 > device in the function(mtk_iommu_config). since there are 4 ports, it > will call device_link_add 4 times. > > > > > and why those additional references can't be cleaned up in an > > orderly fashion? > > If the iommu-consume device(like VDEC above) is removed, It should enter > device_links_driver_cleanup which only ref_put one time. I guess whole > the link should be removed at that time. It seems like Robin had some suggestions about using mtk_iommu_add_device() rather than the attach_dev() to set the links up, and then track them for removal in the corresponding remove_device() callback. Then you wouldn't need this change, right?