Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp5029067imc; Mon, 25 Feb 2019 16:03:20 -0800 (PST) X-Google-Smtp-Source: AHgI3IZWGamCYgXqs0ehXl5qHrWCVJebpVexqQldl7eGk+dPuG9ahzBwYwEYEj5CZiUQF9znfhPi X-Received: by 2002:a63:d814:: with SMTP id b20mr21897146pgh.312.1551139400793; Mon, 25 Feb 2019 16:03:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551139400; cv=none; d=google.com; s=arc-20160816; b=fFxQqYkHQOa7Y91I2j+m3ivphIbMoTngp5WZLl7CvDdyUTQ7RDhuqHvzHyqFwFplir URnH3xFvtUUyw24Iozo3OMn2cEzLQUX1+Z02+DosmhI4mEZonjwMfYSWcY4iQPiRRkSg VPdiMGnG5KeUIZ7DCP8N1kxPT+w+uaoKfKqPDGUNgtNXNvdEzm6QobIF4HzXTcFG+oFl Aw7FshZh4wYu91jNpxyF+d7nnB+luG/Vsh2Eukmc5l5LSYOZg2wQw2c0g8jyMnoCGvRd H86Dc34jSobzOpRakMx4tMfJ0pHrpIOakd8afyAJDt+g0USxcUrVjTLu2OzzDB+HeZ+1 vQqw== 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=t4gY5KZY3j+v6lNL3mYxj3q2uSyGFjZbYwW3PkYe4vQ=; b=esTiIe0IjE82lOun7xPfXbFsgQ5vgF+xsV8ZTIzi/fMbAARAjxt6HHgsuOEoiE/6sF aEbvRSmB65A7d7PN5IGdBfBvg8nWKiLObn8pn3NC328iXldtXLZcbFpDyCImbjfJM2U3 KaPX2eSSjfazwyi7SZWcrTypmu18w7dOluzuX55ZblIf62L3C3jDIjDRynyIhzKhFD4c 9BlXUcbeaWQmco46pqrpcCsET0dqQBAassVmoudN+rcU72dzeQKOaYRvthuKyCBWp/8A hczErc5kQQH+VLFwVtI391gojzudEPstOoazcgXwIFjG4tjm+k34Xrt6Z2o8yn+E9Oo8 00EA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=kc1+7CSQ; 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 e192si10643912pfc.28.2019.02.25.16.03.05; Mon, 25 Feb 2019 16:03:20 -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=kc1+7CSQ; 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 S1729077AbfBZACk (ORCPT + 99 others); Mon, 25 Feb 2019 19:02:40 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:36411 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727529AbfBZACj (ORCPT ); Mon, 25 Feb 2019 19:02:39 -0500 Received: by mail-lj1-f196.google.com with SMTP id v10so9125364lji.3 for ; Mon, 25 Feb 2019 16:02:38 -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=t4gY5KZY3j+v6lNL3mYxj3q2uSyGFjZbYwW3PkYe4vQ=; b=kc1+7CSQghDMEHxybMZNL+zxWbTGNFaeWcmZu7HPhDTWtIO7lYG9IdvAxq6ZoTXRzC vDnzAv0T/CofbIgC+9dAxgfyQWxZ1qqYK22vbAfZ7nUlrQW3DZDcxfN5kp44Hmn6Bcfu 4+XoUuNtGRs/6Mi7l0mTBYa1fDagwO21XumVk= 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=t4gY5KZY3j+v6lNL3mYxj3q2uSyGFjZbYwW3PkYe4vQ=; b=YGOMZksr8m5Zdhw9IWtA87LbBwiKBlkUFlW4tJ6FsyFd6U9/OD6VzJZrvG2BrvmBkU UG7IOoPhqbrgRLujp1rPtPKIlA8HxrzILjQr31NxmjfkvUsfV1TkErldu+uFsmFOosC6 LupjpQnvltgOkAWP1ID5viQ9aJnMF92Qy7HYwlcO+ymFnv2JUOHAmuoKkVDHVFpD1Mru FNzhdvaQv9MI8bYHUHU/iQyNVFBQX4lOkQyagbSjfy6C5YQZIW4CUSURmYss2Z6zjCim HPTIR7ql4d4V8uSLA3eD8l6nwkkG0SkYGUU3WdTIL3x+uc6IIPtI8/8EPQ6xCc3DHg8x vu/g== X-Gm-Message-State: AHQUAubUzZB2jfP3EMkvuEkAa49RdCUx7UifpEV81NzMqF13Gtrj5u90 nveuDVf8kcaFgftv7OJb+wgaurVjkng= X-Received: by 2002:a2e:7314:: with SMTP id o20mr5734121ljc.111.1551139357849; Mon, 25 Feb 2019 16:02:37 -0800 (PST) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com. [209.85.208.177]) by smtp.gmail.com with ESMTPSA id v8sm2582189lji.51.2019.02.25.16.02.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Feb 2019 16:02:37 -0800 (PST) Received: by mail-lj1-f177.google.com with SMTP id z25so9100972ljk.8 for ; Mon, 25 Feb 2019 16:02:37 -0800 (PST) X-Received: by 2002:a2e:9ad1:: with SMTP id p17mr11645266ljj.30.1551138861092; Mon, 25 Feb 2019 15:54:21 -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> In-Reply-To: <1546318276-18993-3-git-send-email-yong.wu@mediatek.com> From: Evan Green Date: Mon, 25 Feb 2019 15:53:44 -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 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, and why those additional references can't be cleaned up in an orderly fashion? (To be honest, I don't really understand the case for the AUTOREMOVE flags at all. Is there some case where the party that set up the link can't tear it down? Or is this a way to devm_ify the link, where devm itself doesn't work because the links themselves stall out that mechanism?)