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=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 0E688C433E7 for ; Fri, 28 Aug 2020 18:42:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E3E0D20737 for ; Fri, 28 Aug 2020 18:42:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="WpnVo7bV"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="ChwUrHsM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728113AbgH1Sm2 (ORCPT ); Fri, 28 Aug 2020 14:42:28 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:47360 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726010AbgH1SmZ (ORCPT ); Fri, 28 Aug 2020 14:42:25 -0400 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1598640142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=i9PL1UZyrvXtvYwXm50JgVKEMKlhclTur/QaPxXNrW4=; b=WpnVo7bVNT/b8XQDt+j58pe6KdQuC0AaMuaG96ld2pT19xmZmgIfhwIL2aToKAQCuHplbl babtlLWVtGtJoKe554lnL+lrSbC+m2P80aoFcGewVi1cvJw89TLCA+RKvIpl3nB1tz+atR Rpt1UAY/0C2Jh7S/HVLrWc1d3i6FRctcoggPvOgispeAzX31o/e0KIecYrxPcVTe02glak xvt/5cf0eEZL35Cs55nb+A3Mx+nimOdxcufa2dUvIghy3OgLuWzePAHaWMcUDkE7FZclcC P6D3MhploGKAumda2RRUUhTFcp/3dtDRczfHHNjGZzGxRU3c3M1LzqDqHVmpHA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1598640142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=i9PL1UZyrvXtvYwXm50JgVKEMKlhclTur/QaPxXNrW4=; b=ChwUrHsMyAvL0EU/Y4hgs1mQPBN+7Zk3PLK+0Sz5YppkJGFQXT2iBnk0EWmZfwq4Jm1Lwb mDs4YAIFWBPd+5CQ== To: Marc Zyngier Cc: LKML , x86@kernel.org, Joerg Roedel , iommu@lists.linux-foundation.org, linux-hyperv@vger.kernel.org, Haiyang Zhang , Jon Derrick , Lu Baolu , Wei Liu , "K. Y. Srinivasan" , Stephen Hemminger , Steve Wahl , Dimitri Sivanich , Russ Anderson , linux-pci@vger.kernel.org, Bjorn Helgaas , Lorenzo Pieralisi , Konrad Rzeszutek Wilk , xen-devel@lists.xenproject.org, Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Greg Kroah-Hartman , "Rafael J. Wysocki" , Megha Dey , Jason Gunthorpe , Dave Jiang , Alex Williamson , Jacob Pan , Baolu Lu , Kevin Tian , Dan Williams Subject: Re: [patch V2 43/46] genirq/msi: Provide and use msi_domain_set_default_info_flags() In-Reply-To: References: <20200826111628.794979401@linutronix.de> <20200826112334.889315931@linutronix.de> Date: Fri, 28 Aug 2020 20:42:21 +0200 Message-ID: <87zh6ek3xu.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 27 2020 at 09:17, Marc Zyngier wrote: > On 2020-08-26 12:17, Thomas Gleixner wrote: >> #ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN >> +void msi_domain_set_default_info_flags(struct msi_domain_info *info) >> +{ >> + /* Required so that a device latches a valid MSI message on startup >> */ >> + info->flags |= MSI_FLAG_ACTIVATE_EARLY; > > As far as I remember the story behind this flag (it's been a while), > it was working around a PCI-specific issue, hence being located in > the PCI code. Yes. Some cards misbehave when there is no valid message programmed and MSI is enabled. > Now, the "program the MSI before enabling it" concept makes sense no > matter what bus this is on, and I wonder why we are even keeping this > flag around. > Can't we just drop it together with the check in > msi_domain_alloc_irqs()? I'm fine with that. Thanks, tglx