From owner-svn-src-all@freebsd.org Thu May 12 21:32:15 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7675AB384EF; Thu, 12 May 2016 21:32:15 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56C3D1F1F; Thu, 12 May 2016 21:32:15 +0000 (UTC) (envelope-from gonzo@freebsd.org) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtp (Exim 4.86 (FreeBSD)) (envelope-from ) id 1b0xaP-000Pwd-VE; Thu, 12 May 2016 13:51:58 -0700 Received: (from gonzo@localhost) by id.bluezbox.com (8.14.9/8.14.9/Submit) id u4CKpvsC099734; Thu, 12 May 2016 13:51:57 -0700 (PDT) (envelope-from gonzo@freebsd.org) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@freebsd.org using -f Date: Thu, 12 May 2016 13:51:56 -0700 From: Oleksandr Tymoshenko To: Ian Lepore Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r299563 - head/sys/dev/gpio Message-ID: <20160512205156.GA99686@bluezbox.com> References: <201605122012.u4CKCkVD040893@repo.freebsd.org> <1463085629.1180.75.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1463085629.1180.75.camel@freebsd.org> X-Operating-System: FreeBSD/10.1-RELEASE (amd64) User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Ian Lepore (ian@freebsd.org) wrote: > On Thu, 2016-05-12 at 20:12 +0000, Oleksandr Tymoshenko wrote: > > Author: gonzo > > Date: Thu May 12 20:12:45 2016 > > New Revision: 299563 > > URL: https://svnweb.freebsd.org/changeset/base/299563 > > > > Log: > > Add gpiobus_release_pin function to release mapped pin > > > > Add gpiobus_release_pin as a counterpart for gpiobus_map_pin. > > Without it it's impossible to properly release pin so if kernel > > module is reloaded it can't re-use pins again > > This reminds me that we (Michael Meloun & I) had talked on irc about > renaming gpiobus_map_pin() to gpiobus_acquire_pin() and adding a > release function. Now we have the release, but its name really doesn't > scream that it's the inverse of map_pin. Is it too late to rename map > to acquire? (I'm not too wed to the 'acquire' name, 'allocate' would > also be a good candidate. We also considered 'reserve' but that had > less of a "now I own it exclusively" feel to it. 'map' didn't feel > quite right because mapping pins in an FDT world is the responsibility > of the pinmux driver, not a gpio thing.) [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 21:32:15 -0000 Ian Lepore (ian@freebsd.org) wrote: > On Thu, 2016-05-12 at 20:12 +0000, Oleksandr Tymoshenko wrote: > > Author: gonzo > > Date: Thu May 12 20:12:45 2016 > > New Revision: 299563 > > URL: https://svnweb.freebsd.org/changeset/base/299563 > > > > Log: > > Add gpiobus_release_pin function to release mapped pin > > > > Add gpiobus_release_pin as a counterpart for gpiobus_map_pin. > > Without it it's impossible to properly release pin so if kernel > > module is reloaded it can't re-use pins again > > This reminds me that we (Michael Meloun & I) had talked on irc about > renaming gpiobus_map_pin() to gpiobus_acquire_pin() and adding a > release function. Now we have the release, but its name really doesn't > scream that it's the inverse of map_pin. Is it too late to rename map > to acquire? (I'm not too wed to the 'acquire' name, 'allocate' would > also be a good candidate. We also considered 'reserve' but that had > less of a "now I own it exclusively" feel to it. 'map' didn't feel > quite right because mapping pins in an FDT world is the responsibility > of the pinmux driver, not a gpio thing.) I do not think it's too late. I guess if you do this before code slush for 11 that should be OK. At least I can not come up with a reason why it can't be done. -- gonzo