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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F2FAC4167D for ; Thu, 2 Nov 2023 12:37:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376336AbjKBMhk (ORCPT ); Thu, 2 Nov 2023 08:37:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40012 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347626AbjKBMhC (ORCPT ); Thu, 2 Nov 2023 08:37:02 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3EFBC199; Thu, 2 Nov 2023 05:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698928475; x=1730464475; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=yCF7BDVIYKalEi/HaZ90Ts9couhyZV50EQlfDFbgZIY=; b=htP2uhNlz6Mlq+wxP2Njc8djy8LZkdugHVw027SxHWCRF/ZY7mxgyNcI jmA34gnwRffGeIY+CUEqjw8sHD4Ee24lvODvjPbpruTJPgykfy/EVx21R I0YU8eh77Wd+JIHkNOKuNVme/uqGM31LKGCMbFiGdV1fdAcdxLZFSpcIf ozUE+fA9Q5qa1F5LttYmRd0jbBRNSjcWxqMnfzsRw1dzecRa/VgXpdJ7O 94Jxy6Vp5qns4vpe4p71Ydu+6tYSeiwWJtKhrogvCE9k7AIpfeb/lmHPQ NjEJgpvI+F/C2IL0z6aWKvOTDlGvFneYvJjlTcUOtAWfqy7Cs7/cNOyfc Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10881"; a="368906158" X-IronPort-AV: E=Sophos;i="6.03,271,1694761200"; d="scan'208";a="368906158" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Nov 2023 05:34:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10881"; a="790383087" X-IronPort-AV: E=Sophos;i="6.03,271,1694761200"; d="scan'208";a="790383087" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga008.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Nov 2023 05:34:32 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.97-RC3) (envelope-from ) id 1qyWu6-0000000AgYp-0xdv; Thu, 02 Nov 2023 14:34:30 +0200 Date: Thu, 2 Nov 2023 14:34:29 +0200 From: Andy Shevchenko To: Linus Walleij Cc: Raag Jadav , linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, Mika Westerberg Subject: Re: [PATCH v1 1/1] pinctrl: tangier: Move default strength assignment to a switch-case Message-ID: References: <20231030155340.3468528-1-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 02, 2023 at 08:36:11AM +0100, Linus Walleij wrote: > On Mon, Oct 30, 2023 at 4:54 PM Andy Shevchenko > wrote: (...) > > + case 1: /* Set default strength value in case none is given */ > > So where does this 1 come from in the end? That's the piece I > am missing in this explanation. Somewhere, someone decided > to pass 1 to indicate "pull to default resistance". > > Is it coming from ACPI firmware? No, it's pure Linux kernel decision. gpio_set_bias() is who made that. That's why it needs to be chosen on global level. We may even document somewhere that arguments let's say up to 10 do not make any sense in real life, as even for 1.2 v it will give 120 mA current on a single pin. Yet, theoretically that's possible for discrete industrial GPIOs, so we can choose "very big number" if such case appears in the future. I don't want to change 1 to something else right now as it may break things. > for default pull" should be added to the constant definition in the > code. -- With Best Regards, Andy Shevchenko