Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp7834288rwn; Wed, 14 Sep 2022 05:19:44 -0700 (PDT) X-Google-Smtp-Source: AA6agR4jioVZNvm3OIaKjSoCXnePd9/9oRcd8D7bPmDC+3EGW2KyHrKfcvasLDUofmOkC1d2NQCY X-Received: by 2002:a17:902:e947:b0:170:d739:8cbe with SMTP id b7-20020a170902e94700b00170d7398cbemr37020737pll.141.1663157984542; Wed, 14 Sep 2022 05:19:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663157984; cv=none; d=google.com; s=arc-20160816; b=mOydPTdosjKYqDSLSPjr9oaTrS9qHYkSpfHxZXosVqnSPcTAY9FAOObLmTuHqmnwYY QsjDaAipjp/HP8pg0NnUBxMtu9CN/kANeC1V4Kt0MqHCMF7vGZbOWmVQjdGHqZbw0vHv /ZxutekEm1x8wFXz5fMKUXrey9sjH866IGjNiekAuqzQoGRlHhfQPXH4F87FAmAgOzYj 780w3rDJMR2v+wy4dyDdJp59Si5xDQJtC+F9ZClhDKeCSve/vCgQchZM/TZd39pGgXYt mI9AmF1HOHixD6+K1Q3OOs9hGAIXwMqEhU8XqFrJ56wLFazye76zRWY7pq+omOa3wDD5 E/Qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=FqrsaO7+mEwEpioRKATgloJ10+QM+/cB58bQ3+4dp5M=; b=kIYDjWm5L7ByAgX2w50/14Ls/rdP6HbIPZTjP0btBqDD/ECA14exSP3HLkB/Q6IUSJ Mt3TGok8TLz1awRvCkA1d2kYQzjSEXsY6JsxZGad2atcpO6jzZN1YmArDX9rsW5M/riU Ph7B3MDRFOaTmjzSxG5ULUT0cVJoji4c83//hOwvj7OevDWUm9e3vUDZinQ08b2BV9dr pvVtwTidS8wbxR4sRVeSpVQqCtqA/3kq2o338F/ZopLJcSl8KbWb2tIG7e1iZMNwQFOk 30uqE48y0r+O5t56V2hxL0T9tN5vLS6W5e/SxKGqU5NlTZgWoGeFX977svkAXR6Edto9 BO8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20210112.gappssmtp.com header.s=20210112 header.b=3ZzWtVRd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id il3-20020a17090b164300b001fd7cab081bsi4156235pjb.125.2022.09.14.05.19.28; Wed, 14 Sep 2022 05:19:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20210112.gappssmtp.com header.s=20210112 header.b=3ZzWtVRd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230164AbiINMK5 (ORCPT + 99 others); Wed, 14 Sep 2022 08:10:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44408 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230192AbiINMKq (ORCPT ); Wed, 14 Sep 2022 08:10:46 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C55B27FFBF for ; Wed, 14 Sep 2022 05:10:34 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id lc7so34290210ejb.0 for ; Wed, 14 Sep 2022 05:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=FqrsaO7+mEwEpioRKATgloJ10+QM+/cB58bQ3+4dp5M=; b=3ZzWtVRdsZPrUXGxn0Qt6WlAedOqYVxlPHkp6kNc9C3ddTB0szCRpmIDODQota/WGL all8CziUkR78153lbchMPecG3kDeC3kZoAgFIYZKZRrzvDWq/b2p+wa9aBKBPgJvbH/0 TM30WUNl9iH1tcAqq7HwNkoliE76c6V+JvHrzBXha8xMzLJCz8raV0O2It47jJ9gvfJN 6LnfS8S/La2rMiNKpmivF3YJRzSJaZXFWTNOmRqV3oUA6VKKqacCGj4g8Zl2SdZs7igL kin69leUUoCFCxja9ttW/w+K2rsiYYYt6edwlYRgmduSDMeVEoIbLp98YWKMXgBKggPR Wtcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=FqrsaO7+mEwEpioRKATgloJ10+QM+/cB58bQ3+4dp5M=; b=DbCfHbLiTdzzLU45pC2z2DA9GJ7dBlFyqqCyQF2yhoL5qLFlAJrkfS5fJ+u8KLVuV1 UhoYJ4dL37MS6rZ2NWrFJhlXCEC28+X84JrDtJZK2g2FyshK218lDrKao6FPJQKMTUTc jujfb/OLTZr4bfIMQtHQaiQS0hivGDabbBXeJyf91NUTDyB+Y//z0sOv9ERHVbd8D6PR xAxPvMzdTOviKovYQN5BAll0D4BhuIlzp+qWMexeoDc40ncG+px2RAm1j+qRxD+q5eVc 9hu1KAYdbbUaNpctRPcFU1CAjrlJAw8vBlt7nSGF+i2PJ7z0kC/HRmg1ukC3Cv8WKDPo uGSg== X-Gm-Message-State: ACgBeo3QZ2GtJ2XJQ0lNce/6otxQAkvB6ZzwvaZ9P0MRuTQ/oAvYlvsU R7Zr8ip3uiUpK701+5hSLMj7mZqZDffUb7phmXTnYQ== X-Received: by 2002:a17:907:3e07:b0:774:53ba:6b27 with SMTP id hp7-20020a1709073e0700b0077453ba6b27mr20640334ejc.286.1663157432337; Wed, 14 Sep 2022 05:10:32 -0700 (PDT) MIME-Version: 1.0 References: <20220906204301.3736813-1-dmitry.torokhov@gmail.com> <20220906204301.3736813-2-dmitry.torokhov@gmail.com> <20220906211628.6u4hbpn4shjcvqel@pali> <20220906214114.vj3v32dzwxz6uqik@pali> <20220906220901.p2c44we7i4c35uvx@pali> In-Reply-To: From: Bartosz Golaszewski Date: Wed, 14 Sep 2022 14:10:21 +0200 Message-ID: Subject: Re: [PATCH 2/2] PCI: mvebu: switch to using gpiod API To: Linus Walleij , Kent Gibson Cc: Dmitry Torokhov , =?UTF-8?Q?Pali_Roh=C3=A1r?= , Shawn Guo , Lorenzo Pieralisi , Thomas Petazzoni , Bjorn Helgaas , Rob Herring , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 14, 2022 at 12:35 PM Linus Walleij wrote: > > On Wed, Sep 7, 2022 at 12:41 AM Dmitry Torokhov > wrote: > > > Linus, do you think we should introduce GPIOD_OUT_INACTIVE / > > GPIOD_OUT_ACTIVE or GPIOD_OUT_DEASSERTED / GPIOD_OUT_ASSERTED and > > deprecate existing GPIOD_OUT_LOW and GPIO_OUT_HIGH? > > They should rather be replaced everywhere in one go. > > I think it is just a half-measure unless we also add > #define GPIOD_ASSERTED 1 > #define GPIOD_DEASSERTED 0 > to be used instead of 1/0 in gpiod_set_value(). > We've had that discussion for libgpiod and went with GPIOD_VALUE_ACTIVE and GPIOD_VALUE_INACTIVE but... > It would also imply changing the signature of the function > gpiod_set_value() to gpiod_set_state() as we are not > really setting a value but a state. > ... now that you've mentioned it it does seem like GPIOD_STATE_ACTIVE/INACTIVE makes much more sense as well as naming the relevant functions gpiod_line_request_set_line_state() etc. > I have thought about changing this, but the problem is that I felt > it should be accompanied with a change fixing as many users > as possible. > > I think this is one of those occasions where we should merge > the new defines, and then send Linus Torvalds a sed script > that he can run at the end of the merge window to change all > gpiod_set_value(...., 1) -> gpiod_set_state(...., GPIOD_ASSERTED); > everywhere. > > After all users are changed, the GPIOD_ASSERTED/DEASSERTED > defined can be turned into an enum. > > That would be the silver bullet against a lot of confusion IMO. > > We would need Bartosz' input on this. > We can also let Linus know that we'll do it ourselves late in the merge window and send a separate PR on Saturday before rc1? Bart > Yours, > Linus Walleij