Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp5573732pxb; Mon, 28 Mar 2022 14:25:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwcdV2ZeEz0eq+c/+E4pBqnlTTewmxcDOl/a2lSHbdssldqRnltvSk0tao3vNffaQ074IsZ X-Received: by 2002:a54:4d05:0:b0:2ef:10d0:f348 with SMTP id v5-20020a544d05000000b002ef10d0f348mr614680oix.278.1648502700714; Mon, 28 Mar 2022 14:25:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648502700; cv=none; d=google.com; s=arc-20160816; b=oRLB+6a/EvnACCPZYxf1mC7wt4tlJHWFokqUnf8hWtOn6F1lo1Xhr2Vvz1E3NKNXhj SD2JsnmeyX+OfIha2GznWfnh+ieqlhYYTXtekF2z1S4WFNLk+A7A6AW0l0xx+BRdFL4Q J1XkQns91amO1YGUUnvxmeHCferGgPo1rW0fxzLq6IkY0TTsl4Rt467vgJ/v7yGfn7VL B9HZKuwHGLNPkxvF68jFmv1QQHyP+yT9TPmL1aYxsIBlrW+KqFyTur8GvHxTAkhpxcrL gjdlEe4uIc3/9MqqgKRlP0AIeoAN1taGl6+3pMFt2lOcLlsd1te6UJsLc6X5ttnpxTr4 lgfA== 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=upE3SDU3C7PmeiFHIHw5TJWEmI++MEjL3taGlr4esD0=; b=xkBnyAjOq9D8s0LEJmkxUhg/Fhyv+AG/PqHHIMz5lsCR6q0Eh958W7+OWnT3ow84vF FzOHgKNRyLVsfMVvkEeT3y80m4MzTXfNkkH7POQ9BIL2MBDtt1OsSUxF4MowedPGWDvW AlY8zLZRDW2gLJOml972yW2UOMktYZ/+f+LCJKwnMBxRCri+amwNcvPVZgcE5i1nO1Mx fPyryDYfp4RZIfWBXueMcToTVk9T2EeDkN5xrZ1ODHJeIPW6nZNB/QfGt5CQuocUDimd xBhvaOJ0D69SLB5xUb1tcMREx7CzUTivvYXCU0b1CreOzXljMugNF5AWpMuEu6uthpc3 DbVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=EfZv6Bq8; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id k23-20020a544717000000b002ef0c34762esi10898834oik.174.2022.03.28.14.25.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Mar 2022 14:25:00 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=EfZv6Bq8; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 022672FFD9; Mon, 28 Mar 2022 14:09:30 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243016AbiC1NQN (ORCPT + 99 others); Mon, 28 Mar 2022 09:16:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48462 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243012AbiC1NQK (ORCPT ); Mon, 28 Mar 2022 09:16:10 -0400 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6BB81F607 for ; Mon, 28 Mar 2022 06:14:29 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id y38so23273912ybi.8 for ; Mon, 28 Mar 2022 06:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=upE3SDU3C7PmeiFHIHw5TJWEmI++MEjL3taGlr4esD0=; b=EfZv6Bq8GrxdsUN0ohm2KNMCUo5KMF5yi14/mzkINXkalQGBmEbg5JnshyBfFMwYEi L0bRXIflaiMXmklQuDXjTbOQ8VVwmJ6RBp2b24Po26k/l0O3ZpHv+ejllmFxJVnuUzUI lndDpXOlYS+7zcXZFG/mjgzvFX3wOdek+LgXZ20NI8aMIUztkQacHCQDLPyBdrbTfjvm HqjQEbyJoGqeEvKI/nRjWCLaG2b6S289WkZL7OIHIzjUVF2eb9Z3Kcx6+BRxb6bGgaII LEc/9VwrqJIbpg171Sd+Z7jfdIVILS3gDjWcd8LeECY+XO9A8THOyIvQCnm10fXhIJ+3 gPfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=upE3SDU3C7PmeiFHIHw5TJWEmI++MEjL3taGlr4esD0=; b=UDRsN1nHZvl8kaCu9/PN6UvlaAmxb66SM9R8Rzw2qDGPv7KDw1vDSVbWYm0Bflh2FS 9NJMznbwaF1Bk8rrLaE0ng+tRFYrnL2x1h/LEVCrinLstJ5bNDeSqPUDtLfkCwLnFc1w oJxhFwtq3griUG3fF6KnQtrLJB0EdYB6zCWHp6vvjySF6GCX+YVar2uhUXyXARXvvaM+ b9Fu1zjXQl7ep5mCZbEPav+o4J5JT34NkNzunXIvKSpLJm3P4atFqIT537kWJs6Vq5pJ LhQTIKwe9PhLE/TlSw2u+T/bBcP/1i8YeVNFvzuA0vA6UQ/jbYdb7kOBqtJJ0vHZ7Sc/ iFJw== X-Gm-Message-State: AOAM533pKxciSLoQXlxYlgWOvKBjqzI/Rsdl6NacFXBe+/8zjjfnEE2o RSkyEnlaPH2nvr6Jaye8/viPYAyBUpbUG3Fvc7Q3bQ== X-Received: by 2002:a25:d088:0:b0:633:b902:2d29 with SMTP id h130-20020a25d088000000b00633b9022d29mr22281939ybg.626.1648473268863; Mon, 28 Mar 2022 06:14:28 -0700 (PDT) MIME-Version: 1.0 References: <20220311043015.4027-1-pshete@nvidia.com> In-Reply-To: From: Linus Walleij Date: Mon, 28 Mar 2022 15:14:17 +0200 Message-ID: Subject: Re: [PATCH] pinctrl: tegra: Set SFIO mode to Mux Register To: Thierry Reding Cc: Prathamesh Shete , jonathanh@nvidia.com, linux-gpio@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, smangipudi@nvidia.com, EJ Hsu Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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, Mar 23, 2022 at 1:31 PM Thierry Reding wrote: > So this is basically what tegra_pinctrl_gpio_disable_free() does. I'm > wondering if we need to do both, though. Are ->gpio_disable_free() and > ->set_mux() always called in tandem? I suspect they are not because > otherwise this wouldn't be needed. > > On the other hand, if ->set_mux() can be called in a code path without > ->gpio_disable_free() then this may be necessary to get the pin out of > SF mode. But that doesn't necessarily mean that the reverse is true. > If it isn't possible for ->gpio_disable_free() to be called in a code > path that doesn't have ->set_mux() then this patch would make the former > implementation redundant. > > That said, upon inspecting the pinmux core, I don't see a 1:1 > correlation between the two, so this seems fine. Yups that's how it works. .gpio_*() callbacks are just a shortcut for enabling/disabling pins into GPIO mode, some drivers don't even use it and rely on users to set up the pin mux with explicit muxing instead. So these APIs are orthogonal. I'll wait for a version of the patch with your explicit reviewed-by though. Yours, Linus Walleij