From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 015111B2; Fri, 1 Dec 2023 07:47:26 -0800 (PST) X-IronPort-AV: E=McAfee;i="6600,9927,10911"; a="395058" X-IronPort-AV: E=Sophos;i="6.04,241,1695711600"; d="scan'208";a="395058" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2023 07:47:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10911"; a="769715259" X-IronPort-AV: E=Sophos;i="6.04,241,1695711600"; d="scan'208";a="769715259" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga002.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Dec 2023 07:47:22 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.97) (envelope-from ) id 1r95jb-000000011kj-2Ljl; Fri, 01 Dec 2023 17:47:19 +0200 Date: Fri, 1 Dec 2023 17:47:19 +0200 From: Andy Shevchenko To: Nuno =?iso-8859-1?Q?S=E1?= Cc: Linus Walleij , nuno.sa@analog.com, linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Jean Delvare , Guenter Roeck , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Jonathan Corbet , Bartosz Golaszewski Subject: Re: [PATCH v2 2/2] hwmon: ltc4282: add support for the LTC4282 chip Message-ID: References: <6384831c05b8ceeaf4a16cf9229770252989b762.camel@gmail.com> <971eb35068639ec404669ea5320c8183ea71a7d0.camel@gmail.com> <61a8f54835c10db7a9c650ee2e3706b47382c634.camel@gmail.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo On Fri, Dec 01, 2023 at 04:24:35PM +0100, Nuno Sá wrote: > On Fri, 2023-12-01 at 14:40 +0100, Linus Walleij wrote: ... > Yes, that is the only thing we have. Meaning that there is no hw setting to set the > pins to open drain. Open drain is what they are. That is why I'm not seeing the point > in having PIN_CONFIG_DRIVE_OPEN_DRAIN implemented. At least you have to implement error for PUSH_PULL mode and other modes, so from the (core) software point of view the user should be able to ask for anything and get an answer from the certain driver that "hey, i do support OD", or "hey, push-pull can't be supported with this hw". -- With Best Regards, Andy Shevchenko