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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 49681C5519F for ; Sun, 22 Nov 2020 13:39:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EDBE02076E for ; Sun, 22 Nov 2020 13:39:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ST2EMlBW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727817AbgKVNi6 (ORCPT ); Sun, 22 Nov 2020 08:38:58 -0500 Received: from mail.kernel.org ([198.145.29.99]:55670 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727646AbgKVNi5 (ORCPT ); Sun, 22 Nov 2020 08:38:57 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7B7F92076E; Sun, 22 Nov 2020 13:38:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606052336; bh=Lv5DzjMq8Mlus4xbHuVC7Ai+4Y/6Rbn2W4UWbEa0T/I=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ST2EMlBWWxsJDC+UePmnrz6G6StDpsWFW6QQEtB+7yJlHbrTeEW585rakSCgWBr1n yj7j6h50cOVNT09J27TP3L0qHzkUY33fx1/FxF6QdtUXBJItQhOYCnKIYjvtTLIt4M CfI6FxNpuWi1/67VOKezd/qZ+22ZxIpchrgPORUQ= Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kgpZu-00Chhl-D6; Sun, 22 Nov 2020 13:38:54 +0000 Date: Sun, 22 Nov 2020 13:38:53 +0000 Message-ID: <87sg91ik9e.wl-maz@kernel.org> From: Marc Zyngier To: John Garry Cc: Thomas Gleixner , , , , , , , Subject: Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc() In-Reply-To: <4aab9d3b-6ca6-01c5-f840-459f945c7577@huawei.com> References: <87ft57r7v3.fsf@nanos.tec.linutronix.de> <78356caa-57a0-b807-fe52-8f12d36c1789@huawei.com> <874klmqu2r.fsf@nanos.tec.linutronix.de> <87lfexp6am.fsf@nanos.tec.linutronix.de> <3acb7fde-eae2-a223-9cfd-f409cc2abba6@huawei.com> <873615oy8a.fsf@nanos.tec.linutronix.de> <4aab9d3b-6ca6-01c5-f840-459f945c7577@huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26.3 (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 X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: john.garry@huawei.com, tglx@linutronix.de, gregkh@linuxfoundation.org, rafael@kernel.org, martin.petersen@oracle.com, jejb@linux.ibm.com, linuxarm@huawei.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org 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-kernel@vger.kernel.org On Fri, 20 Nov 2020 11:52:09 +0000, John Garry wrote: > > Hi Thomas, > > >> Just mentioning a couple of things here, which could be a clue to what > >> is going on: > >> - the device is behind mbigen secondary irq controller > >> - the flow in the LLDD is to allocate all 128 interrupts during probe, > >> but we only register handlers for a subset with device managed API > > Right, but if the driver is removed then the interrupts should be > > deallocated, right? > > > > When removing the driver we just call free_irq(), which removes the > handler and disables the interrupt. > > But about the irq_desc, this is created when the mapping is created in > irq_create_fwspec_mapping(), and I don't see this being torn down in > the driver removal, so persistent in that regard. If the irq_descs are created via the platform_get_irq() calls in platform_get_irqs_affinity(), I'd expect some equivalent helper to tear things down as a result, calling irq_dispose_mapping() behind the scenes. > So for pci msi I can see that we free the irq_desc in > pci_disable_msi() -> free_msi_irqs() -> msi_domain_free_irqs() ... > > So what I am missing here? I'm not sure the paths are strictly equivalent. On the PCI side, we can have something that completely driver agnostic, as it is all architectural. In your case, only the endpoint driver knows about what happens, and needs to free things accordingly. Finally, there is the issue in your driver that everything is requested using devm_request_irq, which cannot play nicely with an explicit irq_desc teardown. You'll probably need to provide the equivalent devm helpers for your driver to safely be taken down. Thanks, M. -- Without deviation from the norm, progress is not possible.