From owner-freebsd-current@freebsd.org Thu Oct 24 16:01:39 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 60302170824 for ; Thu, 24 Oct 2019 16:01:39 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46zX6p4JP4z3wmV; Thu, 24 Oct 2019 16:01:38 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f182.google.com with SMTP id u22so7606957lji.7; Thu, 24 Oct 2019 09:01:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=2fTIsw4f/rwGDs4/gH/my7iad6DTbKaP/pYVvMzajC8=; b=InoUfnHa7H/g4lrbxBpWGbS4eDdsHwUpmmBCozsODKF1tgYq9XBIEU7bLFbmGeicpK omAbv2vV5LUHCm5GjUeReyXU08Sh4rnKEDIL0rR+k/o/So0YoQU61MYyYcL7iEUc5UQi YtOMyDNl7dR8sdkC2Kv8iXSVdqmypCmVcVAg+KtsW6CzH3ZUU9BlnwikmvfrUa97TR7+ w7qESbHeXaqd9FOVezOVa139gKMvuuXm/otH/Iq7yvArZZGV56ZWudf8XBKFUqeKhr+c 0mtYPvaqnfznRHTmkMX6HEIONdSYr3xAM5MEagIztKLrOb3gdYyqhRIOD/kOiEEYqjxR f8zw== X-Gm-Message-State: APjAAAUpXibtqpfUQqMG4fbPYJDMEynBqf1Mmjn96k4VfRJlO5cF5Wb+ XyQTnSIKo6S1c+FCUBj2Z8gTDA+3nwU= X-Google-Smtp-Source: APXvYqyjbf7BE3+Uq3XMdl4RAEf5m2rRA+9+92YiExQH5xP0/R3wE3ZPIBUbrp/z3J4/bKP2wG2ORg== X-Received: by 2002:a2e:9702:: with SMTP id r2mr9457019lji.194.1571932896044; Thu, 24 Oct 2019 09:01:36 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id x1sm22098222lff.90.2019.10.24.09.01.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Oct 2019 09:01:35 -0700 (PDT) Subject: Re: gpiobus: setting output value while in input mode To: Ian Lepore , FreeBSD Current References: From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= mQINBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABtB5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz6JAlQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryLkCDQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAYkCPAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: Date: Thu, 24 Oct 2019 19:01:34 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46zX6p4JP4z3wmV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of agapon@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=agapon@gmail.com X-Spamd-Result: default: False [-3.18 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.18)[ip: (-0.56), ipnet: 209.85.128.0/17(-3.23), asn: 15169(-2.06), country: US(-0.05)]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[182.208.85.209.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FORGED_SENDER(0.30)[avg@FreeBSD.org,agapon@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[182.208.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[avg@FreeBSD.org,agapon@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[96.151.72.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] 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 16:01:39 -0000 On 24/10/2019 18:38, Ian Lepore wrote: > 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. Another possibility: 4) always reject the operation under that condition >> >> 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? Well, I think that it is a choice between affected consumer drivers needing to have some boiler plate code to handle the error and all GPIO controller drivers needing to have some code to handle GPIO_PIN_PRESET. I am not sure which one is less work. That is, I am not sure how many consumer drivers really *require* the preset behavior. Another issue is that we probably need to make *all* controller drivers support GPIO_PIN_PRESET before any consumer drivers can start using it without extra checks, fallback code, etc. Also, if we universally implement GPIO_PIN_PRESET we still need to answer the question. Because some consumer might still try to change an input, either by mistake or for some reason, and we need a rule on how to handle that. > 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. That would be great! gpio would certainly benefit from more documentation. -- Andriy Gapon