Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4141750ybi; Mon, 29 Jul 2019 20:10:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqzDz2bvzcMmZzv3v9uPg5XJQCmwuyZ4peKGQTEU13PS/XNjP5qzUacTbW/mkfZn4tNv3ZJX X-Received: by 2002:a17:90a:b387:: with SMTP id e7mr25751024pjr.113.1564456211075; Mon, 29 Jul 2019 20:10:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564456211; cv=none; d=google.com; s=arc-20160816; b=RwnTMkf3cN0nBo10LFhY7nAnbq6Aav/eAU8Zhl2mBz2Ggp3TDxa/7WZkcGm5bagbs6 DsfVwijlSJz7gZ3LAMZvef4O9YpPf52ufn2DxWFCeFfxMcyvT5aWbuXsJdYrxJ5IyU/c wjiOBLuFslJPYDuncYnAe2zwsyefzWLdcAwxL1Kvrjc85r6CEa8xMa5Wo5411lSMnN7O W+Q4OvPOEUT/Kk61XFeCXaQXXKw9BhSC0pkD5PqpDjqmC3rLXq8rvWUt7eQFvftvblO1 x4inWFy9RcNpFA+dz6Xpvi++4rdwCdIf0zuK04MXRyO7xRILdCoPYRv5iHDOCipRAQIQ OxLQ== 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; bh=Y260FQuMp7oPWM+HPu4498GOZAdUH2RolhKd2463kTQ=; b=ZuvPwvKWhpO+QD0KqBVtGhEDRV2JGH3MEX0RFtXI1U/66HtdeJi+JVy1T1LYjGxYth Jx42/fAvxTu1XBMb6QECWTbsgck/OqAa7s0I5nwkLk/NhxL+95PgwugeROXboo2420D+ Agf/0F72W4EnO6wwNucg1gN9t6TAAvHrNoK+2JIh3wL7QMNVQo2ZedbIpwguek8/6JxY VLBhWDZWaYD3Tala6jdnSSWgh0pDqWeo/hiPEBL3kbKPeVnBV8Hi1vUpSXY0mhfiz+LN k4V5/IWAlH6MuiEXPSmHYaopBGJa6pY+eFrKratHsJP6lTwge7nrz+6Wvwel10z/RNV0 xtSw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c64si26120494pje.9.2019.07.29.20.09.56; Mon, 29 Jul 2019 20:10:11 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728370AbfG2WD7 (ORCPT + 99 others); Mon, 29 Jul 2019 18:03:59 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:35187 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726173AbfG2WD7 (ORCPT ); Mon, 29 Jul 2019 18:03:59 -0400 Received: by mail-oi1-f195.google.com with SMTP id a127so46403368oii.2; Mon, 29 Jul 2019 15:03:58 -0700 (PDT) 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=Y260FQuMp7oPWM+HPu4498GOZAdUH2RolhKd2463kTQ=; b=qqjEDoejrqI/NPnKzOvjaY0KKkDJpR4oF/Lsu0gUpyUvacK99U670zYqEcTJ5JD/ad P0uJlaTk+J0TqEVPFHnUTjebwwKK+LNacoWXa+4ZKT9pR2B7k7f9yk0KVfApP4hNEWbn 5Be3HWgZpcVgj1+o9QGDOFF02qRtkFM/Ksfn3J4lUwbVAIAr497/bMahnsH7LSnOG6/+ gYfJjcQfOeTvsZ2qE2Fh5U6h9+k2/c82JLhaFEgLfnW8jyai9N1Bd3x5kYQhnCkvjnGD XkYOl7mfsxm8pwgXg4tEzYqYsMtIFJGrsOQ4PVqajfHOanAQx+DeMIgYzu6U9axqR/Dj rJgQ== X-Gm-Message-State: APjAAAXnVWOqmwzSWvMvfGQFwYnQwsmFm/oLqaA9Rt3Q9WT5eyeDluxO 68+mMpK/YRCgYAVC0kMr6HShYWibrI4xykwAjhc= X-Received: by 2002:aca:4e89:: with SMTP id c131mr54969535oib.57.1564437838483; Mon, 29 Jul 2019 15:03:58 -0700 (PDT) MIME-Version: 1.0 References: <2305283.AStDPdUUnE@kreacher> In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 30 Jul 2019 00:03:47 +0200 Message-ID: Subject: Re: [PATCH v2] driver core: Remove device link creation limitation To: Saravana Kannan Cc: "Rafael J. Wysocki" , Dmitry Osipenko , "Rafael J. Wysocki" , Greg Kroah-Hartman , LKML , Linux PM , Lukas Wunner , Jon Hunter , Ulf Hansson , Marek Szyprowski , "linux-tegra@vger.kernel.org" , Thierry Reding 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, Jul 29, 2019 at 11:43 PM Saravana Kannan wrote: > > On Mon, Jul 29, 2019 at 2:25 PM Rafael J. Wysocki wrote: > > > > On Mon, Jul 29, 2019 at 10:47 PM Saravana Kannan wrote: > > > > > > Rafael, > > > > > > This is the fix you need. Or something link this. > > > > > > I had asked you to reject DL_FLAG_MANAGED as an input flag if you are > > > marking it as internal (in the comments). But looks like you were also > > > trying to check for "undefined" bit positions. However, the check > > > isn't correct because DL_MANAGED_FLAGS doesn't include (rightfully so) > > > DL_FLAG_PM_RUNTIME and DL_FLAG_RPM_ACTIVE . > > > > > > I tried to write a DL_FLAG_EXTERNAL to include all the external flags, > > > but that felt like a maintenance headache that's not worth carrying. I > > > think it's simpler to just error out when internal flags being passed > > > in and ignore any undefined bit positions. > > > > Well, IMO it is better to prevent people from passing unrecognized > > flags to device_link_add() at all, even if that means some extra > > effort when adding new flags. > > It isn't so much the extra effort that's a concern, but people might > miss updating whatever grouping macro we use. > > > > > I'll post an alternative fix shortly. > > You might want to move the MANAGED_FLAGs and other grouping macros > into the header file then? So that if someone is adding new flags, > it'll be less likely they'll forget to update the grouping macro? They would need to update device_link_add() itself, so updating a thing next to it does't seem to be so much of an issue. Moreover, the "grouping macro" is not relevant for any users of the API, just for device_link_add() itself, so I'm not sure how much better it is to have it in the header. And, of course, if anyone forgets to update the "grouping macro", they will find that the new flags are rejected immediately.