From owner-freebsd-current@freebsd.org Thu Oct 24 15:38:38 2019 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7F7CF16FF09 for ; Thu, 24 Oct 2019 15:38:38 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46zWcG0YZdz3Q59 for ; Thu, 24 Oct 2019 15:38:37 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1571931516; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=UZKFUfk4rbbZr9g04uE1BGC0qoLgNpRG5C/9M+h1we8cleuHKAhZ2ze4OXa9rJ8FPSksBkw77Ij83 LpVvyA1fxrbqVdB2uycw9abLJ79EqMyTr67JesPOjI+BT0p77vgkdu7qA/swCWwIiirGtHda708Ppi YbBbsOf7sFR3idNFOngDnhpeyYAYjCgGFriI/vTijyWNy5sgCT3mQkzUOza4kv2UybnHIDt7gMTmPC wRi0yvp4gA00FAlp5uyQfg9par1i/VwT04p+UgBlZiBUfLB5W6uGNp5kfOzkNY8f4X75sZyl/NqZTr LsQOxolND+W28nd/NoGI7/Kpu9acSNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=/nttioeiY8Kbi+SO2ySRQ1mjrfzGRXV7cQ3EwSS1LnU=; b=JIhXxKn1HO2JRhTpb1nNwar+GoRhXZzqJ/3Vjb+TM1E+OCTbaA4UaCMQgjr+mC6oGjoM1aiUyMyPW sZGfSUAfLgK7qpZxKNndQ7FBtJV8lUfzGAx6ZmJq83HTA3we+eCCR2tkJFO+VSAs0gZHGEU/HQMzh8 A9E4SGkqL5E/+EIQV3E236tMq+uBfbALuIv8nwqA1QIFDAQq/eNsalBQh63r+KAq4yuGa4oK3ELie3 zCQp0awWI5IFOypXnS9OYS+Dgm5PMMANiJWUieKFjwZgGD1YDt7plCLuUll95Zv33WZsL4VEpy2kDe pWa9JRNXT4WjxPohlvnE9t8Z4zUG0xA== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=/nttioeiY8Kbi+SO2ySRQ1mjrfzGRXV7cQ3EwSS1LnU=; b=D+LFghfanBnUbKGff7WSXryvE8n8x46Op043vpsZSspEHD50pkGXSwjb9dTzGDx8TeAJs4F1ct27X AD7lL1Pi2kcwfN9QcY5pFi8qXFQGwn6e6N3fOfOEnBi1OPlFYqxBLR7K7ShCP4jNNkkVilue+8hVa6 y9wfiB84m7jlaz4SEWD8TOp17+LzHHP+r95WiAJC9TiHzFiiRSgu9N+9R2fNArf0+hlU/RApjJGzHi Zin1mWleBfIrQWiaSQMftRw8qli+jFb0CPpXXKptoGANgLy0qK6HhmGM8eI0cZ7UTEUGSSl1S+VfWc pr4zk6dBHNxxtlXfO9i/JyKe2p82KMQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: 56e17c1f-f674-11e9-829e-79a40d15cccd X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 56e17c1f-f674-11e9-829e-79a40d15cccd; Thu, 24 Oct 2019 15:38:35 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x9OFcYrx045295; Thu, 24 Oct 2019 09:38:34 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: gpiobus: setting output value while in input mode From: Ian Lepore To: Andriy Gapon , FreeBSD Current Date: Thu, 24 Oct 2019 09:38:34 -0600 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46zWcG0YZdz3Q59 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.86 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.86)[-0.862,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 15:38:38 -0000 On Thu, 2019-10-24 at 17:04 +0300, Andriy Gapon wrote: > For a lack of a more specific mailing list (or my not being aware of it), asking > here. > > gpioiic, a very simple driver, has this code: > =========================================================================== > static void > gpioiic_setsda(device_t dev, int val) > { > struct gpioiic_softc *sc = device_get_softc(dev); > > if (val == 0) { > GPIOBUS_PIN_SET(sc->sc_busdev, sc->sc_dev, sc->sda_pin, 0); > GPIOBUS_PIN_SETFLAGS(sc->sc_busdev, sc->sc_dev, sc->sda_pin, > GPIO_PIN_OUTPUT); > } else { > GPIOBUS_PIN_SETFLAGS(sc->sc_busdev, sc->sc_dev, sc->sda_pin, > GPIO_PIN_INPUT); > } > } > =========================================================================== > > The interesting case is val == 0. > > I know that there are GPIO controllers where input and output values are > represented by different bits, so it is possible to set a future output value > while the pin is in input mode. > At the same time, there are controllers where there is a single bit per pin and > while the pin is input mode the bit is read-only. So, it is impossible to > preset the pin. > > How should controllers of the second type handle GPIOBUS_PIN_SET when the pin is > in input mode? > I see three options: > 1) just silently ignore GPIOBUS_PIN_SET or do it in a more glorious way: go all > the way to the hardware without caring if that does anything; > 2) return an error that would hint that the operation is not possible at this time; > 3) try to emulate the first class of controllers; that is, stash the value to > apply it when the pin is switched to output mode. > > I personally prefer 2, it's not hard to do (unlike 3) and there would be at > least some visibility into the problem. > A couple years ago I added new flags GPIO_PIN_PRESET_{LOW,HIGH}. Maybe we should document (where?) that the proper way to achieve the effect the code wants in the val==0 case is to use the preset flag along with the OUTPUT flag. The driver will preset the pin before changing it to output if it is able to do so, otherwise it will do the best it can, which is to set the pin to output, then set its value, perhaps generating a brief bogus state followed by a transition to the right state. Then of course we'd have to fix all existing drivers to behave that way, but I don't think that will be hard. My problem with #2 is that whenever you push the problem out to the child drivers, one of two things happens: drivers ignore the error, or all drivers have to have essentially identical code to handle the error. In this case, what could a child driver do except react to the error by doing the operations in the reverse order? The current gpio(4) documentation really only covers gpiobus(4) and a mentions a few of its older children and how to configure them via hints. We need manpages for some of the newer drivers, and we especially need a manpage that documents sys/gpio.h (which is used both from userland and internally with gpio_if.m). I can probably find some manpage-writing time over the new few weeks. -- Ian