From patchwork Fri Jan 26 19:02:00 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Jan_Kundr=C3=A1t?= X-Patchwork-Id: 866568 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-gpio-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=cesnet.cz header.i=@cesnet.cz header.b="JMHd2+9O"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3zSqW71XBXz9sNr for ; Sat, 27 Jan 2018 06:59:47 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751408AbeAZT7p (ORCPT ); Fri, 26 Jan 2018 14:59:45 -0500 Received: from office2.cesnet.cz ([195.113.144.244]:60176 "EHLO office2.cesnet.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751212AbeAZT7o (ORCPT ); Fri, 26 Jan 2018 14:59:44 -0500 Received: from localhost (unknown [IPv6:2001:718:1:2c:4c87:d4a8:de7f:541e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id B51F0400064; Fri, 26 Jan 2018 20:59:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1516996783; bh=/xsemt+6hwE3yGztWLbYmWaInmBTp3kXcHrMLanjQjY=; h=Resent-Date:Resent-From:Resent-To:Resent-Cc:From:Date:Subject:To: Cc; b=JMHd2+9OKwcBb0SsKpGFWwqBfHIGcCdMMCsp97X5qgDwCnKtJssMqgVu/0OJkFeM8 LrB/igvBjrPF54ZPm7VbK3unCKyXNPA6vU3TnZU1+yqO3z+WKIZSxn3/V36mEeqjTm nUvzvSmgj2eG989P5L9psDsRZS97hjZKskNpmdDY= Message-Id: From: =?utf-8?q?Jan_Kundr=C3=A1t?= Date: Fri, 26 Jan 2018 20:02:00 +0100 Subject: [PATCH] gpio: serial: max310x: Use HW type for gpio_chip's label MIME-Version: 1.0 To: linux-gpio@vger.kernel.org Cc: linux-serial@vger.kernel.org, Linus Walleij , Greg Kroah-Hartman , Alexander Shiyan Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org Some debugging tools (/sys/kernel/debug/gpio, `lsgpio`) use the gpio_chip's label for displaying an additional context. Right now, the information duplicates stuff which is already available from the parent's device. This is how e.g. `lsgpio`'s output looks like: GPIO chip: gpiochip2, "spi1.2", 16 GPIO lines Comparing the output of other GPIO expanders that I have available: gpiochip4: GPIOs 464-479, parent: spi/spi1.1, mcp23s17, can sleep: gpiochip5: GPIOs 448-463, parent: i2c/0-0020, pca9555, can sleep: gpiochip2: GPIOs 496-511, parent: spi/spi1.2, spi1.2, can sleep: This patch ensures that the type of the real HW device is shown instead of duplicating the SPI path: gpiochip2: GPIOs 496-511, parent: spi/spi1.2, MAX14830, can sleep: Signed-off-by: Jan Kundrát Reviewed-by: Linus Walleij --- drivers/tty/serial/max310x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c index 39f635812077..efe55a1a0615 100644 --- a/drivers/tty/serial/max310x.c +++ b/drivers/tty/serial/max310x.c @@ -1318,7 +1318,7 @@ static int max310x_probe(struct device *dev, struct max310x_devtype *devtype, /* Setup GPIO cotroller */ s->gpio.owner = THIS_MODULE; s->gpio.parent = dev; - s->gpio.label = dev_name(dev); + s->gpio.label = devtype->name; s->gpio.direction_input = max310x_gpio_direction_input; s->gpio.get = max310x_gpio_get; s->gpio.direction_output= max310x_gpio_direction_output;