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 ED9B6C433EF for ; Mon, 25 Jul 2022 13:25:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235532AbiGYNZo (ORCPT ); Mon, 25 Jul 2022 09:25:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235503AbiGYNZl (ORCPT ); Mon, 25 Jul 2022 09:25:41 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E7E05FD5; Mon, 25 Jul 2022 06:25:40 -0700 (PDT) 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 41933B80EC9; Mon, 25 Jul 2022 13:25:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 077A4C341C6; Mon, 25 Jul 2022 13:25:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658755538; bh=qrNmI0+Xi+leg5oQ8lCWj5IMys4zFhzyyUUPjKowDQM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FjV2jFZAh5LeAxLAXTzPUIDAOPSRfx8adWMLvncWhPIi8+8nk5pkhsSrtoGljxlXv df7RE1rdESD0AXyST3Fn9C7VXlPn+ilAmwBDS4ueIpUJO2hmL6jzbWJ7O5dWAhbha3 0Hk0m/LaaEaYf1t3FlFlegWo+Jr0sNspRb/udpgWyVyyv/ak3+GCRXmxiKUTewnxkx UDXvfZQ4WoWgmph0tEQ8T6CUnUknAQZh7+PIFpExApROf+bqMHjsFtgkpwt1Z8UiXT a5yb2KYJwHeZfpryFYMTDWsg7bCwyIsvHL5JF30K8z1iec0QNZgk7MbLjID+C0pBF6 q1CsuIDsBG+Lg== Received: from johan by xi.lan with local (Exim 4.94.2) (envelope-from ) id 1oFy5l-0007Zq-GE; Mon, 25 Jul 2022 15:25:49 +0200 Date: Mon, 25 Jul 2022 15:25:49 +0200 From: Johan Hovold To: Bjorn Helgaas Cc: Pali =?utf-8?B?Um9ow6Fy?= , Johan Hovold , Kishon Vijay Abraham I , Xiaowei Song , Binghui Wang , Thierry Reding , Ryder Lee , Jianjun Wang , linux-pci@vger.kernel.org, Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Ley Foon Tan , linux-kernel@vger.kernel.org, Marc Zyngier Subject: Re: Why set .suppress_bind_attrs even though .remove() implemented? Message-ID: References: <20220722143858.GA1818206@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220722143858.GA1818206@bhelgaas> Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org [ +CC: maz ] On Fri, Jul 22, 2022 at 09:38:58AM -0500, Bjorn Helgaas wrote: > On Fri, Jul 22, 2022 at 03:26:44PM +0200, Johan Hovold wrote: > > On Thu, Jul 21, 2022 at 05:21:22PM -0500, Bjorn Helgaas wrote: > > > > qcom is a DWC driver, so all the IRQ stuff happens in > > > dw_pcie_host_init(). qcom_pcie_remove() does call > > > dw_pcie_host_deinit(), which calls irq_domain_remove(), but nobody > > > calls irq_dispose_mapping(). > > > > > > I'm thoroughly confused by all this. But I suspect that maybe I > > > should drop the "make qcom modular" patch because it seems susceptible > > > to this problem: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ctrl/qcom&id=41b68c2d097e > > > > That should not be necessary. > > > > As you note above, interrupt handling is implemented in dwc core so if > > there are any issue here at all, which I doubt, then all of the dwc > > drivers that currently can be built as modules would all be broken and > > this would need to be fixed in core. > > I don't know yet whether there's an issue. We need a clear argument > for why there is or is not. The fact that others might be broken is > not an argument for breaking another one ;) It's not breaking anything that is currently working, and if there's some corner case during module unload, that's not the end of the world either. It's a feature useful for developers and no one expects remove code to be perfect (e.g. resilient against someone trying to break it by doing things in parallel, etc.). > > I've been using the modular pcie-qcom patch for months now, unloading > > and reloading the driver repeatedly to test power sequencing, without > > noticing any problems whatsoever. > > Pali's commit log suggests that unloading the module is not, by > itself, enough to trigger the problem: > > https://lore.kernel.org/linux-pci/20220709161858.15031-1-pali@kernel.org/ > > Can you test the scenario he mentions? Turns out the pcie-qcom driver does not support legacy interrupts so there's no risk of there being any lingering mappings if I understand things correctly. Johan