From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2AEC6C76186 for ; Mon, 29 Jul 2019 22:14:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 01E282073F for ; Mon, 29 Jul 2019 22:14:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GDOHpV5z" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728669AbfG2WOM (ORCPT ); Mon, 29 Jul 2019 18:14:12 -0400 Received: from mail-ot1-f68.google.com ([209.85.210.68]:34113 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726327AbfG2WOL (ORCPT ); Mon, 29 Jul 2019 18:14:11 -0400 Received: by mail-ot1-f68.google.com with SMTP id n5so64269126otk.1 for ; Mon, 29 Jul 2019 15:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=srsaV7rzeEymjAzgSWNLmNrniFdnk6Pa83TgYZnyX/o=; b=GDOHpV5z0vkTp/Hi9k2G9RgZZVziD9cVw4u/mDbabUF6fthqBEpD/8MLgeaoZ54AXl gp0l4hXk6AWGC2IzW4ii/4UQEBxzajmUlkfHWmKxGm24d+k5C45V0pg1L+oyVAX4YD7u h8NXxkhTqhfvFrBdj6h4GOpXGJxxrvxpRVDn2kNMV7WMhIA18dWbtiofquPD9NoIBfQ7 zUVtuqXW4rzQFaGb7Feac5wlgC92z0LPraATDJ2Qo9/hSoW6qpBPmDv2n5UdUAi0DT04 q2OHystI5so/Rgnn1bJznS4CHAiSrfhiNNdMDQZ4lT+pZ8/1qrm3uIT8I4LhsfaGG8f7 F5Ew== 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=srsaV7rzeEymjAzgSWNLmNrniFdnk6Pa83TgYZnyX/o=; b=HOq+N7l88ll0S4cPwpBi+rEnJGmaTt2y1lCjzx1FOZxL1yWhxRDF2OdtgcUEGVatUh X0x+WgIm1FoP/krrnGB1erzCww09pJg5jz7DThjPcxoYMLL9rv7SEHfWby2YuUaEqh+M miz9jCHUjkvc0jG20hsNEzqQGAXJ0HomLNyBepvger8gVzr4WwViwyUHykrNwcd7XGov q482Jm72v3InquKfShCbaMg30FsKv0dTX460rzWMedG8obgX3xuBnR8FECGVzNKYc/A4 WuP4/XnjCvKY8z/at8MOsGnLJu2kelcQU9jnHMcJZAGWrmX3llDG7ULS1qFxgfd6mYX/ gQpA== X-Gm-Message-State: APjAAAVNSMsKgeKo74TZZy5FWTj1dSjwePeFq5mharK9+0CTVycANa1h LDwAHF2iZvam59VasQIZwfdThQeRFvbBcObvc9rX+Q== X-Google-Smtp-Source: APXvYqyuO53DWB1GnZbL8WPgAO6wYlxjhUKdDeUSsQXNzJYXk94EMFolKbpzDqKJBJk8IqgjhsI+ynp/TAB7yS3S1qk= X-Received: by 2002:a9d:6201:: with SMTP id g1mr85088815otj.195.1564438450498; Mon, 29 Jul 2019 15:14:10 -0700 (PDT) MIME-Version: 1.0 References: <2305283.AStDPdUUnE@kreacher> In-Reply-To: From: Saravana Kannan Date: Mon, 29 Jul 2019 15:13:34 -0700 Message-ID: Subject: Re: [PATCH v2] driver core: Remove device link creation limitation To: "Rafael J. Wysocki" Cc: 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 3:03 PM Rafael J. Wysocki wrote: > > 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. Sounds good. -Saravana