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 1CB6DC433F5 for ; Fri, 11 Feb 2022 09:20:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346106AbiBKJU0 (ORCPT ); Fri, 11 Feb 2022 04:20:26 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:33072 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346668AbiBKJUX (ORCPT ); Fri, 11 Feb 2022 04:20:23 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 71967337; Fri, 11 Feb 2022 01:20:22 -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 ams.source.kernel.org (Postfix) with ESMTPS id 2CC05B82877; Fri, 11 Feb 2022 09:20:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA115C340ED; Fri, 11 Feb 2022 09:20:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644571220; bh=n75wa6NR9fx2urlJ3HKHsSkqoRez52riwHs8303NTZM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OJ8INf16qTwj2WVyT5UMDyjKBd9xwrfOZ3ZYv2pV+Duu7kNnfBA/tLMI0oyU6MJAw 1DXXbw4DU/pMYejMc1ImA3j1M8O1tro74D6g+6r0gsRFuexTwyBURnM16o8IfQ/I9x 77Q/rIO/uwAZcDjcoPZFnHYeoWWziUDorFvHSuf7JqmllIxCCbAT2oxE7XDTRjeP1y xvsHSgJFf83Ji9caoaACPNBPyu65z3dIb55v74sN3/IorG8y28HlkNbSKBf2buCamC NvBhnjHrXSgnXbGkVO70Wx4IJEZpUtLg7FCNMeirJA73jFx2Lo9DSRihuJ+z2vfFfg YlYuTHMF5sPkQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=billy-the-mountain.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 1nIS6D-0077gv-Ul; Fri, 11 Feb 2022 09:20:18 +0000 Date: Fri, 11 Feb 2022 09:20:17 +0000 Message-ID: <87ee49lpym.wl-maz@kernel.org> From: Marc Zyngier To: Linus Walleij Cc: Emil Renner Berthing , 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> 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 (aarch64-unknown-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 X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: linus.walleij@linaro.org, kernel@esmil.dk, 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 On Fri, 11 Feb 2022 00:15:25 +0000, Linus Walleij wrote: > > On Thu, Feb 10, 2022 at 10:06 AM Marc Zyngier wrote: > > On Wed, 09 Feb 2022 23:30:55 +0000, > > Emil Renner Berthing wrote: > > > > The gpio framework seems to fill in default handlers in the struct > > > above, so unfortunately it can't yet be made const. Is this something > > > you intend to fix in the future? > > > > This is next on my list of things to address. The whole 'let's copy a > > whole irqchip structure and hijack random pointers' should not have > > happened, and it certainly is going to be an interesting ride. > > Sorry about that... Probably my bad idea. The only upside is that the > things that are ugly are centralized to one spot. No worries. I should have kept an eye on that too and spotted it earlier. It is only when helping with the M1 GPIO driver that this was brought to my attention. My current approach is to move each and every driver to using the existing helpers, and advertise to the core GPIO code that they don't need to be fiddled with a new irqchip flag. It is a rather simple change, but there are a lot of drivers (I have so far converted the Apple, Qualcomm and Tegra186 drivers, as this is the HW I have around), allowing their irq_chip structures to be made const and only used by reference. Once all drivers are converted (one day), we can drop the flag and the pointer swapping code. The alternative approach was to use a hierarchical irqchip provided by the GPIO code, but this proved difficult as it would need to know which methods to implement depending on the flow used. There are also only a handful of drivers using the hierarchical mode anyway, and we'd be stuck for all the other drivers. Anyway, I'll post something shortly with the stuff I have changed, and we can happily repaint that bike shed. Thanks, M. -- Without deviation from the norm, progress is not possible.