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 19F3EC433F5 for ; Wed, 23 Mar 2022 08:57:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242972AbiCWI7Z (ORCPT ); Wed, 23 Mar 2022 04:59:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237212AbiCWI7Y (ORCPT ); Wed, 23 Mar 2022 04:59:24 -0400 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F55F72E07 for ; Wed, 23 Mar 2022 01:57:52 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id bu29so1603052lfb.0 for ; Wed, 23 Mar 2022 01:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=waldekranz-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=+qaXC3e57Tiy30ZXHo3R6JiVE4H5pqyKCj5fJD4m4ys=; b=zqNNso2fFQIURdKn+WCA/vJQdsxFIVL22/L/nbroH9TaQ5BMjR9n+6Qg4QmAR/7Q4b jxP6IL+fSjauUtN0GUsgR5rScJGv/jpBLVydr0e7AG0CmeTB6iIgC8goReiBaudA8nC0 lmIS4pgYLY4nqwCxRznov31I79k3xiuaCGMqac26PV9V8Nwp/dA7Ri/tqKwsNpX9OL1W EJuMCxFR4sx2DB+N+ZVNRgrrSfGWuynXnK4FIFTBgC2miCWqxn1o4apcFsxQcoVyQIL7 XnhlHsW+2m6Xzvk25IsPVBqYFOCE1YNoPHHrO+PX8+Fa+35BE7DUFrVAyhHOdEoTdF5d 9qdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=+qaXC3e57Tiy30ZXHo3R6JiVE4H5pqyKCj5fJD4m4ys=; b=ySsUIwlGPhpI7DHfuFYeRuiWukPXS5kwgccd0/EvSniDGphBQf94u9HTH2pnWuL0ll ixOxUEbhSQ1F+3FrJ4A9fpzcoP9X8vaNY0vt0MUbMYSJLkKU7OFJ96X578jW4E/SU3Pz I2kWeIz2wc5DubppMyCGg/4BSvPUldUVXO7Uu8jCc+5UIzg5Olk0uM2OQtjgAw7ujOGx rn8muro5h5pRk+pGXiGRK/+Tyi1MVpihC0493pKhav1CM2EYcEsT/fdsVe3IH3fM9dka emv2IQXP9NnC4wRtCJS6Ru9UOjMCbILL6pBDzZ+b15C9nJ5Uh9WhKN9dUJDJlwDGWykU T1+w== X-Gm-Message-State: AOAM5308e9Z4HWIAcXbXxDaLEN05j1k6kb7sPGK3wbVjp73rmrOgn3Wj DqJQZRKdi/8GfXSzheMJut3FRm31qG/WdQ== X-Google-Smtp-Source: ABdhPJx/2cLioJKyQq21MTxnrumXwt4HgT60/HKz/TXrfghvo/u6E3itGwmET3Nei+dOXQ78PmJ4Pw== X-Received: by 2002:a05:6512:1585:b0:445:908b:ad71 with SMTP id bp5-20020a056512158500b00445908bad71mr20542778lfb.200.1648025870850; Wed, 23 Mar 2022 01:57:50 -0700 (PDT) Received: from wkz-x280 (a124.broadband3.quicknet.se. [46.17.184.124]) by smtp.gmail.com with ESMTPSA id y23-20020a2e95d7000000b00247e4e386aasm2684910ljh.121.2022.03.23.01.57.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Mar 2022 01:57:49 -0700 (PDT) From: Tobias Waldekranz To: Guenter Roeck , Wim Van Sebroeck Cc: linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] watchdog: gpio_wdt: Support GPO lines with the toggle algorithm In-Reply-To: <8b41a486-92af-2f2d-ba05-205650a90ee2@roeck-us.net> References: <20220322222911.519238-1-tobias@waldekranz.com> <8b41a486-92af-2f2d-ba05-205650a90ee2@roeck-us.net> Date: Wed, 23 Mar 2022 09:57:49 +0100 Message-ID: <87tubphwqa.fsf@waldekranz.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-watchdog@vger.kernel.org On Tue, Mar 22, 2022 at 17:04, Guenter Roeck wrote: > On 3/22/22 15:29, Tobias Waldekranz wrote: >> Support using GPO lines (i.e. GPIOs that are output-only) with >> gpio_wdt using the "toggle" algorithm. >> >> Since its inception, gpio_wdt has configured its GPIO line as an input >> when using the "toggle" algorithm, even though it is used as an output >> when kicking. This needlessly barred hardware with output-only pins >> from using the driver. >> >> Signed-off-by: Tobias Waldekranz >> --- >> >> Hi, >> >> This patch has been in our downstream tree for a long time. We need it >> because our kick GPIO can't be used as an input. >> >> What I really can't figure out is why the driver would request the pin >> as in input, when it's always going to end up being used as an output >> anyway. >> >> So I thought I'd send it upstream in the hopes of either getting it >> merged, or an explanation as to why it is needed. >> > > I _think_ the assumption / idea was that "toggle" implies that the output > is connected to a pull-up resistor and that the pin either floats or is > pulled down to ground, causing the signal to toggle. I don't know if/how > that works in practice, though. Ah I see. Yeah I'm not sure it has the intended effect. AFAIK, that type of connection should be specified using the GPIOD_OUT_LOW_OPEN_DRAIN flag, no? Beyond that though, it seems unnecessary for the driver to impose that restriction. If an open drain configuration is required on the GPIO, then I think that should be specified via the device tree. Looking at some code, gpiod_configure_flags seems to support this: if (lflags & GPIO_OPEN_DRAIN) set_bit(FLAG_OPEN_DRAIN, &desc->flags); else if (dflags & GPIOD_FLAGS_BIT_OPEN_DRAIN) { /* * This enforces open drain mode from the consumer side. * This is necessary for some busses like I2C, but the lookup * should *REALLY* have specified them as open drain in the * first place, so print a little warning here. */ set_bit(FLAG_OPEN_DRAIN, &desc->flags); gpiod_warn(desc, "enforced open drain please flag it properly in DT/ACPI DSDT/board file\n"); } In other words, a DT node like this... &watchdog { compatible = "linux,wdt-gpio"; gpios = <&my-gpio 42 GPIO_ACTIVE_HIGH>; }; ...the GPIO will behave like it does with the "level" algo today. If an open-drain config is required, using this binding... &watchdog { compatible = "linux,wdt-gpio"; gpios = <&my-gpio 42 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>; }; ...will give you that. In other words, with this patch applied, the setup of the GPIO is completely deferred to the device tree. In the general case, my guess is that who ever wrote that has a better chance of specifying the correct flags.