From patchwork Mon May 2 22:24:10 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 67050 Delivered-To: patch@linaro.org Received: by 10.140.92.199 with SMTP id b65csp279347qge; Mon, 2 May 2016 15:24:29 -0700 (PDT) X-Received: by 10.98.15.142 with SMTP id 14mr55105710pfp.6.1462227869564; Mon, 02 May 2016 15:24:29 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j9si351109paf.186.2016.05.02.15.24.29; Mon, 02 May 2016 15:24:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-gpio-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-gpio-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-gpio-owner@vger.kernel.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932226AbcEBWYS (ORCPT + 4 others); Mon, 2 May 2016 18:24:18 -0400 Received: from mail-lf0-f42.google.com ([209.85.215.42]:35348 "EHLO mail-lf0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932205AbcEBWYQ (ORCPT ); Mon, 2 May 2016 18:24:16 -0400 Received: by mail-lf0-f42.google.com with SMTP id j8so2322204lfd.2 for ; Mon, 02 May 2016 15:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=zuRbzvBlhdR4BzsdcsKiKEAn6jbLCYQUgxe8i+tSDVI=; b=gILeRZDUhZlC2m31Kg4arrMJxU9dFqiRJHNLvgSS6PTj3Vubco+4P/U4XZkrj8FiR2 RmTPZ2/7/lnYCXb4/W3PY6VZ96Ez18Xhlo6gO1WI8T/1xNmumEtlPsxL1UePALFCAKmN q7/Lye1VTx49SavWIUKatCGvEj+J1Iz6sqEHI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=zuRbzvBlhdR4BzsdcsKiKEAn6jbLCYQUgxe8i+tSDVI=; b=dRsbQ+QiW9Wy0YOkr11kw2XDB/c/ZHKbDDJJGfD/h4lPBK+CkGaPKKjA5EZ96F69AT TgkwkCPD/o2+VxG2wScsQ9fl2sYSsfyzyfiP3ttSkaFD5daoNj1hpot+CCiUdO20vPVA /ugrcQ0ggpZr1Ff3ztUxojWo3+x1DidYyXMT1rw5XktGxmD8rf9CZr1bVKtnidkAGjZn xH9AoZKQVSEbSVE6HMNlLkvARQ9PeaBYj3jjRXH+Nxd4s/aGMEubxd85bp4ipfYLdKC9 qk1xf3s0aHB7eBpXek8DfmCrznoTI0vrLbaa7n9Z2eTaWVNDoDA8kGz3CnQ0wJZDpKc9 cmjA== X-Gm-Message-State: AOPr4FVyroFUYwvn7dq6yThh0Z9N4IWee8METR//bpONR3BHzJ8r2T7m6htaTZ+LigmF1UGr X-Received: by 10.25.79.12 with SMTP id d12mr16099540lfb.68.1462227853985; Mon, 02 May 2016 15:24:13 -0700 (PDT) Received: from localhost.localdomain.localdomain (c-927b71d5.014-348-6c756e10.cust.bredbandsbolaget.se. [213.113.123.146]) by smtp.gmail.com with ESMTPSA id qh4sm43447lbb.43.2016.05.02.15.24.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 May 2016 15:24:12 -0700 (PDT) From: Linus Walleij To: linux-gpio@vger.kernel.org, Alexandre Courbot Cc: Linus Walleij , Rob Herring , Grant Likely , Amit Kucheria , David Mandala , Lee Campbell , devicetree@vger.kernel.org Subject: [PATCH v4] gpio: of: make it possible to name GPIO lines Date: Tue, 3 May 2016 00:24:10 +0200 Message-Id: <1462227850-7756-1-git-send-email-linus.walleij@linaro.org> X-Mailer: git-send-email 2.4.11 Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org Make it possible to name the producer side of a GPIO line using a "gpio-line-names" property array, modeled on the "clock-output-names" property from the clock bindings. This naming is especially useful for: - Debugging: lines are named after function, not just opaque offset numbers. - Exploration: systems where some or all GPIO lines are available to end users, such as prototyping, one-off's "makerspace usecases" users are helped by the names of the GPIO lines when tinkering. This usecase has been surfacing recently. The gpio-line-names attribute is completely optional. Example output from lsgpio on a patched Snowball tree: GPIO chip: gpiochip6, "8000e180.gpio", 32 GPIO lines line 0: unnamed unused line 1: "AP_GPIO161" "extkb3" [kernel] line 2: "AP_GPIO162" "extkb4" [kernel] line 3: "ACCELEROMETER_INT1_RDY" unused [kernel] line 4: "ACCELEROMETER_INT2" unused line 5: "MAG_DRDY" unused [kernel] line 6: "GYRO_DRDY" unused [kernel] line 7: "RSTn_MLC" unused line 8: "RSTn_SLC" unused line 9: "GYRO_INT" unused line 10: "UART_WAKE" unused line 11: "GBF_RESET" unused line 12: unnamed unused Cc: Rob Herring Cc: Grant Likely Cc: Amit Kucheria Cc: David Mandala Cc: Lee Campbell Cc: devicetree@vger.kernel.org Reviewed-by: Michael Welling Signed-off-by: Linus Walleij --- ChangeLog v3->v4: - Do not use the bool accessor to see if a line is there, use the return value from counting the strings to bail out if <= 0. - Augment the naming loop to be smarter. ChangeLog v2->v3: - Swap "gpio-names" for "gpio-line-names" as "gpio-names" indicate a consumer endpoint in DT terminology. - Index to either: (A) The end of the gpio-names array or (B) ngpios So we don't risk going out of bounds on either ChangeLog v1->v2: - Make the naming function return void: we continue at all times and always return 0 anyway. - Fix a return value check. This has been discussed at some length now. Why we are not using hogs: these are consumer side, not producer side. The gpio-controller in DT (gpio_chip in Linux) is a producer, not a consumer. This patch is not about assigning initial values to GPIO lines. That is an orthogonal usecase. This is just about naming lines. --- Documentation/devicetree/bindings/gpio/gpio.txt | 19 ++++++++++ drivers/gpio/gpiolib-of.c | 49 +++++++++++++++++++++++++ 2 files changed, 68 insertions(+) -- 2.4.11 -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Acked-by: Rob Herring diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index c88d2ccb05ca..68d28f62a6f4 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -152,6 +152,21 @@ additional bitmask is needed to specify which GPIOs are actually in use, and which are dummies. The bindings for this case has not yet been specified, but should be specified if/when such hardware appears. +Optionally, a GPIO controller may have a "gpio-line-names" property. This is +an array of strings defining the names of the GPIO lines going out of the +GPIO controller. This name should be the most meaningful producer name +for the system, such as a rail name indicating the usage. Package names +such as pin name are discouraged: such lines have opaque names (since they +are by definition generic purpose) and such names are usually not very +helpful. For example "MMC-CD", "Red LED Vdd" and "ethernet reset" are +reasonable line names as they describe what the line is used for. "GPIO0" +is not a good name to give to a GPIO line. Placeholders are discouraged: +rather use the "" (blank string) if the use of the GPIO line is undefined +in your design. The names are assigned starting from line offset 0 from +left to right from the passed array. An incomplete array (where the number +of passed named are less than ngpios) will still be used up until the last +provided valid line index. + Example: gpio-controller@00000000 { @@ -160,6 +175,10 @@ gpio-controller@00000000 { gpio-controller; #gpio-cells = <2>; ngpios = <18>; + gpio-line-names = "MMC-CD", "MMC-WP", "VDD eth", "RST eth", "LED R", + "LED G", "LED B", "Col A", "Col B", "Col C", "Col D", + "Row A", "Row B", "Row C", "Row D", "NMI button", + "poweroff", "reset"; } The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c index d81dbd8e90d9..d22dcc38179d 100644 --- a/drivers/gpio/gpiolib-of.c +++ b/drivers/gpio/gpiolib-of.c @@ -196,6 +196,51 @@ static struct gpio_desc *of_parse_own_gpio(struct device_node *np, } /** + * of_gpiochip_set_names() - set up the names of the lines + * @chip: GPIO chip whose lines should be named, if possible + */ +static void of_gpiochip_set_names(struct gpio_chip *gc) +{ + struct gpio_device *gdev = gc->gpiodev; + struct device_node *np = gc->of_node; + int i; + int nstrings; + + nstrings = of_property_count_strings(np, "gpio-line-names"); + if (nstrings <= 0) + /* Lines names not present */ + return; + + /* This is normally not what you want */ + if (gdev->ngpio != nstrings) + dev_info(&gdev->dev, "gpio-line-names specifies %d line " + "names but there are %d lines on the chip\n", + nstrings, gdev->ngpio); + + /* + * Make sure to not index beyond the end of the number of descriptors + * of the GPIO device. + */ + for (i = 0; i < gdev->ngpio; i++) { + const char *name; + int ret; + + ret = of_property_read_string_index(np, + "gpio-line-names", + i, + &name); + if (ret) { + if (ret != -ENODATA) + dev_err(&gdev->dev, + "unable to name line %d: %d\n", + i, ret); + break; + } + gdev->descs[i].name = name; + } +} + +/** * of_gpiochip_scan_gpios - Scan gpio-controller for gpio definitions * @chip: gpio chip to act on * @@ -445,6 +490,10 @@ int of_gpiochip_add(struct gpio_chip *chip) if (status) return status; + /* If the chip defines names itself, these take precedence */ + if (!chip->names) + of_gpiochip_set_names(chip); + of_node_get(chip->of_node); return of_gpiochip_scan_gpios(chip);