Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp949070pxb; Thu, 28 Jan 2021 04:36:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJxBNT8o9G7vjdpLIcNXk1tYNRtR9OQ9ICaIiz3gaeDtaT7+2ePoh3M2xGMShEXgFVO7iQTM X-Received: by 2002:a05:6402:1341:: with SMTP id y1mr13766568edw.273.1611837416822; Thu, 28 Jan 2021 04:36:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611837416; cv=none; d=google.com; s=arc-20160816; b=gyYsGg8ijpEpI3hMRLxoDNQB31TJrAnaRV83SttYdV0n7dNQM7nfboja3iwYXRBU8/ e994nVl6u4GkiM6Z9jm0UPmfRmWYLHyMe/r84CnYq33kT0hCzqLw1Yi2iMnRi7m3RhMS KyKZINx0TVnIj4SZDk1ktTmhYsEr5ic4e2A6oonQ8//NPRQ3cAs9cPNMQbm8HDax11Xn sScom59Bnlnx1hSjNAPlii+wYgkmMiHjVsZq6RdfGSf4dwYc1W3OIT0+YFeVgoJaDERm 9slP15fAHicxnG2geO9FSJKNm36LUBGxASYLOU4Nx5Zf3Tz0kdlx8SHKrldpAfhxsFVr ZLJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=pVl5qIhxVh+00zTAzCYvt4LT4H9/lL4DXEEkxosReIo=; b=sXKOrDICpyUw+VJsOPO3scrvyfyUNAJnrMMnWye5PWsNPsbD54lBMFy3rvKYICX99s zZG3WtqzGL6F4tMhybTiqG9WXJDINm+ErEaCGQImzpalnfWlRB2bJ14Y6h7ueEGzT+mi nryVtkFN22Y4wN80SIHJw2zxmULdQdUmwi6sSSoreYsC7Qdd5/MAmt20JZjDvQmPDCd6 h49h5YReYzeWR9OOERtxbyQU0kQ26v2Qx4Lybr0BrlULcG47fj/3dwYSSLaq954/8De0 hdC06x8u1L/tYIV3uAj0CzeGj4TV0ZbCvL2R/2lHi/uoYLvOgAp0lYL7rWCQA4/R3WIi g11A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q15si2875539edr.397.2021.01.28.04.36.31; Thu, 28 Jan 2021 04:36:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231232AbhA1MdV (ORCPT + 99 others); Thu, 28 Jan 2021 07:33:21 -0500 Received: from foss.arm.com ([217.140.110.172]:58166 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231171AbhA1MdP (ORCPT ); Thu, 28 Jan 2021 07:33:15 -0500 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 Cc: Dmitry Torokhov , Maxime Ripard , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Icenowy Zheng , Rob Herring , =?UTF-8?B?Q2w=?= =?UTF-8?B?w6ltZW50IFDDqXJvbg==?= , Shuosheng Huang , Yangtao Li , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com, Lee Jones , linux-input@vger.kernel.org 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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