From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BDC03C433F5 for ; Thu, 10 Feb 2022 14:34:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242971AbiBJOeJ (ORCPT ); Thu, 10 Feb 2022 09:34:09 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:46860 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236150AbiBJOeI (ORCPT ); Thu, 10 Feb 2022 09:34:08 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BFE6233; Thu, 10 Feb 2022 06:34:09 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3F538619F3; Thu, 10 Feb 2022 14:34:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98068C340E5; Thu, 10 Feb 2022 14:34:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644503648; bh=SXAZ5/YLYmlUTYA3rw+pgO5OvHv3+PnXWuUz7xNb8j4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BuiX8aK/naj9+yu1TVGz5os4lPGGDL6GH62Kq1aGpbCGnYmS8nPN6vCN3UmLdgh4j TkstSrx948cu7U4VLlUpKxx4e3s6zvsHtU9442ugKGWwl+qhVNoxqSedtRTDUK3NUZ /n9eUKeQiDomXE7jo5L/naCm+mFrJRQzzk65Epgq06FNDNybbKk/Rq42zgFYOYM8LE bvjuUvsDvsUJLebyVMS+AvYTNpL4SDvJ7pjMAxBOvA8Q+RssRSCm2pHSXRR7VjpJXn 9Pu2CaN0Ac65cyP+Un5/WkV6p5S8ilNv7uM2OmBvnTO/2lUUtvH+0AUGm95QP/CWvo 3j9ltcwe7tqDQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nIAWM-006vav-Ix; Thu, 10 Feb 2022 14:34:06 +0000 Date: Thu, 10 Feb 2022 14:34:06 +0000 Message-ID: <87pmnu4wpt.wl-maz@kernel.org> From: Marc Zyngier To: Emil Renner Berthing , Linus Walleij Cc: Linux Kernel Mailing List , "open list:GPIO SUBSYSTEM" , Bartosz Golaszewski , Matthias Brugger , Grygorii Strashko , Santosh Shilimkar , Kevin Hilman , Tony Lindgren , Thomas Gleixner , Vladimir Zapolskiy , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , kernel-team@android.com Subject: Re: [PATCH 10/10] pinctrl: starfive: Switch to dynamic chip name output In-Reply-To: References: <20220209162607.1118325-1-maz@kernel.org> <20220209162607.1118325-11-maz@kernel.org> <87zgmz3xbf.wl-maz@kernel.org> <87v8xm4zkm.wl-maz@kernel.org> <87tud64yqa.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: kernel@esmil.dk, linus.walleij@linaro.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, brgl@bgdev.pl, matthias.bgg@gmail.com, grygorii.strashko@ti.com, ssantosh@kernel.org, khilman@kernel.org, tony@atomide.com, tglx@linutronix.de, vz@mleia.com, andrew@lunn.ch, gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org [resending, as I managed to royally screw up my initial email] On Thu, 10 Feb 2022 14:14:19 +0000, Emil Renner Berthing wrote: >=20 > On Thu, 10 Feb 2022 at 14:50, Marc Zyngier wrote: > > On Thu, 10 Feb 2022 13:44:12 +0000, > > Emil Renner Berthing wrote: > > > > > > Gotcha. The SoC has been out in very few numbers for less than a year > > > and the driver only entered mainline in 5.17-rc1, so I doubt anyone > > > has had time to write scripts that check for this, but I'll let it be > > > up to you. > > > > Ah, I should have checked that. In which case, would you be OK if I > > simply pushed the removal of this label as a fix for 5.17, and just > > have it to say "Star5 GPIO", for example, without any indication of > > the device (which appears in debugfs anyway as part of the irqdomain)? >=20 > I'm fine with it although I'd prefer "StarFive GPIO". I haven't seen > star5 used anywhere. Fair enough. > But shouldn't changes like this normally go through Linus Walleij's > tree? Either way, I don't mind. For the record, see below what I'm suggesting we take in before 5.17-final. Linus? Thanks, M. =46rom a84b83c32048de2ba72e5d05645eabc95ffabe49 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Thu, 10 Feb 2022 14:13:36 +0000 Subject: [PATCH] pinctrl: starfive: Use a static name for the GPIO irq_chip Drop the device name used for the GPIO irq_chip and replace it with something static. The information is still available from debugfs and carried as part of the irqdomain. Suggested-by: Emil Renner Berthing Signed-off-by: Marc Zyngier --- drivers/pinctrl/pinctrl-starfive.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/pinctrl-starfive.c b/drivers/pinctrl/pinctrl-s= tarfive.c index 0b912152a405..266da41a6162 100644 --- a/drivers/pinctrl/pinctrl-starfive.c +++ b/drivers/pinctrl/pinctrl-starfive.c @@ -1164,6 +1164,7 @@ static int starfive_irq_set_type(struct irq_data *d, = unsigned int trigger) } =20 static struct irq_chip starfive_irq_chip =3D { + .name =3D "StarFive GPIO", .irq_ack =3D starfive_irq_ack, .irq_mask =3D starfive_irq_mask, .irq_mask_ack =3D starfive_irq_mask_ack, @@ -1308,7 +1309,6 @@ static int starfive_probe(struct platform_device *pde= v) sfp->gc.ngpio =3D NR_GPIOS; =20 starfive_irq_chip.parent_device =3D dev; - starfive_irq_chip.name =3D sfp->gc.label; =20 sfp->gc.irq.chip =3D &starfive_irq_chip; sfp->gc.irq.parent_handler =3D starfive_gpio_irq_handler; --=20 2.34.1 --=20 Without deviation from the norm, progress is not possible. --=20 Without deviation from the norm, progress is not possible.