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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 09D05C43381 for ; Mon, 4 Mar 2019 20:18:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D31E3206B6 for ; Mon, 4 Mar 2019 20:18:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726054AbfCDUSX convert rfc822-to-8bit (ORCPT ); Mon, 4 Mar 2019 15:18:23 -0500 Received: from foss.arm.com ([217.140.101.70]:39494 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726038AbfCDUSW (ORCPT ); Mon, 4 Mar 2019 15:18:22 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 12C6DA78; Mon, 4 Mar 2019 12:18:22 -0800 (PST) Received: from big-swifty.misterjones.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BCB7A3F706; Mon, 4 Mar 2019 12:18:19 -0800 (PST) Date: Mon, 04 Mar 2019 20:18:13 +0000 Message-ID: <86ef7m1ji2.wl-marc.zyngier@arm.com> From: Marc Zyngier To: Lucas Stach , Gustavo Pimentel Cc: Bjorn Helgaas , Jingoo Han , Lorenzo Pieralisi , , Tim Harvey , , Subject: Re: [PATCH] PCI: dwc: skip MSI init if MSIs have been explicitly disabled In-Reply-To: <1551728385.9298.18.camel@pengutronix.de> References: <20190227165219.31911-1-l.stach@pengutronix.de> <20190304192548.GB26569@google.com> <1551728385.9298.18.camel@pengutronix.de> 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 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: ARM Ltd MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org Hi both, On Mon, 04 Mar 2019 19:39:45 +0000, Lucas Stach wrote: > > Hi Bjorn, > > Am Montag, den 04.03.2019, 13:25 -0600 schrieb Bjorn Helgaas: > > [+cc Marc, in case you have any suggestions] > > > > Hi Lucas, > > > > Nit: this has already been merged, but next time please make the > > subject line match the convention wrt capitalization. This is not a > > PCI-specific idea; all it takes is "git log --oneline ", and > > that should be common practice anywhere in the kernel. > > Sorry about that. I didn't really notice the capitalization, but > focused on the prefix. > > > On Wed, Feb 27, 2019 at 05:52:19PM +0100, Lucas Stach wrote: > > > Since 7c5925afbc58 (PCI: dwc: Move MSI IRQs allocation to IRQ domains > > > hierarchical API) the MSI init claims one of the controller IRQs as a > > > chained IRQ line for the MSI controller. On some designs, like the i.MX6, > > > this line is shared with a PCIe legacy IRQ. When the line is claimed for > > > the MSI domain, any device trying to use this legacy IRQs will fail to > > > request this IRQ line. > > > > > > As MSI and legacy IRQs are already mutually exclusive on the DWC core, > > > as the core won't forward any legacy IRQs once any MSI has been enabled, > > > users wishing to use legacy IRQs already need to explictly disable MSI > > > support (usually via the pci=nomsi kernel commandline option). To avoid > > > any issues with MSI conflicting with legacy IRQs, just skip all of the > > > DWC MSI initalization, including the IRQ line claim, when MSI is disabled. > > > > Does this mean that if we have a device that uses legacy IRQs, the > > user has to figure out to boot with "pci=nomsi"? > > As long as there is only a single device connected and there are no > port services things will work. If port services are active, those will > start to use MSIs, breaking legacy IRQs in the process. > > I've asked Synopsys if there is a workaround for this, but it seems > that the core is working "as designed" with no workaround for this icky > behavior. Is this the general DWC controller behaviour? Or something that is specific to a given implementation? I can't believe someone actually thought this is an acceptable behaviour... Gustavo, can you please check with your HW colleagues and let everybody know what's the official Synopsys position on this? > > > I don't like kernel command line parameters. If we need that > > parameter to make devices with legacy IRQs work, what happens without > > the parameter? How obvious is it that the fix is to use "pci=nomsi"? > > Totally non-obvious currently. Maybe this warrants a warning in the > kernel log. > > > Is it impossible for Linux to figure this out and make it work > > automatically? > > > > If we can't do it automatically, fine, maybe we have to live with the > > parameter. But if there's any way we can avoid it, we should. > > I don't think there is a practical way to make this work > automatically. > > At PCIe enumeration time we can only know if all devices in the > hierarchy are able to use MSIs, but this doesn't mean the device driver > will use MSIs. This is something we only get to know at driver probe > time, at which point it may already be too late, as another device > might already use some MSIs, so we can't revert to legacy IRQs only > mode. It is almost as the default is backward. It feels like it should default to legacy interrupts, and only enable MSIs if the user actually asks for it. We should always be able to provide legacy interrupts, as this is the usual fallback for most drivers. Thanks, M. -- Jazz is not dead, it just smell funny.