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 X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D984FC433E0 for ; Thu, 28 Jan 2021 12:33:44 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 691B164DDC for ; Thu, 28 Jan 2021 12:33:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 691B164DDC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2yI0dRFTFWU0XAJFq274xLNYFPImcXulwZ7IjkCNwMc=; b=a1nyALic37qqIBoo+cUGpKsPq DshyewaIffkIzJD33uqdwTfC3/SUX9D8q8XeeosPli8/csqpd2rQGMkaLZxBu7LwAX91yTIqOHG0O PhETxutNpbxDQrdsudRPkGMRRf6z2MaccvRxcJySRIhNHy/e+Jr/UcL+iS/YcI5Je6OXn5spOu3QX tAgqp7DQ67U0rNIrLnN3VwGoMibrW4hrjlB7hZ7+3hme1Pw13cAvjY7eAEdOtyO+h3HIxBK1XEvF4 9vWmrCmGiZBj6zHSUn1DNBQIZiW13SEkIfpc+a4/yjbEnGgmFeFV0uAlAMcIcBHnO8MH1zXJpKd5w NXcXtHtMg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l56TQ-0001qP-Rq; Thu, 28 Jan 2021 12:32:32 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l56TN-0001pq-GT for linux-arm-kernel@lists.infradead.org; Thu, 28 Jan 2021 12:32:30 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 65A4931B; Thu, 28 Jan 2021 04:32:27 -0800 (PST) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 08E7D3F719; Thu, 28 Jan 2021 04:32:24 -0800 (PST) Date: Thu, 28 Jan 2021 12:31:36 +0000 From: Andre Przywara To: Mark Brown Subject: Re: [PATCH v5 05/20] Input: axp20x-pek: Bail out if AXP has no interrupt line connected Message-ID: <20210128123136.417eea7c@slackpad.fritz.box> In-Reply-To: <20210128113601.GA4537@sirena.org.uk> References: <20210127172500.13356-1-andre.przywara@arm.com> <20210127172500.13356-6-andre.przywara@arm.com> <20210128104627.76b35a5c@slackpad.fritz.box> <20210128113601.GA4537@sirena.org.uk> Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210128_073229_672577_F4C2BEFA X-CRM114-Status: GOOD ( 28.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jernej Skrabec , Samuel Holland , Yangtao Li , linux-sunxi@googlegroups.com, Dmitry Torokhov , linux-kernel@vger.kernel.org, Maxime Ripard , Chen-Yu Tsai , =?UTF-8?B?Q2w=?= =?UTF-8?B?w6ltZW50IFDDqXJvbg==?= , linux-input@vger.kernel.org, Shuosheng Huang , Lee Jones , linux-arm-kernel@lists.infradead.org, Icenowy Zheng Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 28 Jan 2021 11:36:01 +0000 Mark Brown wrote: > On Thu, Jan 28, 2021 at 11:11:28AM +0000, Andre Przywara wrote: > > Dmitry Torokhov wrote: > > > On Wed, Jan 27, 2021 at 05:24:45PM +0000, Andre Przywara wrote: > > > > > Check for the regmap_irqc member to be not NULL before proceeding with > > > > probe. This gets normally filled by the call to regmap_add_irq_chip(), > > > > which we allow to skip now, when the DT node lacks an interrupt > > > > property. > > It sounds like you're trying to register an IRQ chip with a somehow > bogus configuration? Quick background: Those AXP PMICs have an IRQ pin, that was always connected to the NMI pin on Allwinner SoCs. This was used for the power button GPIO interrupt. Now the H616 does not have this pin anymore, and the board does not use a GPIO either. I patched the AXP MFD driver [1] to skip the regmap-irq creation when no interrupts DT property was found, but this NULL pointer now understandably confuses the -pek driver, and leads to this crash: http://lists.infradead.org/pipermail/linux-arm-kernel/2021-January/634969.html Hence I wanted to plug this hole, which seems useful regardless of this particular issue. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2021-January/634971.html > > > No, the driver is not the right place to patch this; regmap should be > > > fixed so it does not crash instead. > > > I am not sure this is the right approach, those regmap functions look > > more like an internal interface to me, with lots of wrapper functions > > happily dereferencing pointers and reaching into structs. Moving > > NULL checks into those does not sound like the right thing. CC:ing Mark > > for more opinions on this. > > Without having seen the actual issue if you're trying to register an > interrupt controller with a known broken hardware configuration that > does seem like something the caller just shouldn't be doing, it's not > something that's going to transiently happen at runtime and we're very > much trusting that the caller got things right. > > > A more general solution would be to not instantiate this driver here > > at all, when we don't have an interrupt line. > > However at the moment the AXP MFD driver uses a const struct to hold > > all MFD cells, so there is no easy way of omitting the power key > > device dynamically. And even then it would hard code the requirement > > for an interrupt into the MFD driver, when this could be considered an > > implementation detail of the axp20x-pek driver. > > Another approach is to just register the optional device separately. I will have a look at how much this takes. Thanks, Andre _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel