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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 8F7F4C433E0 for ; Fri, 26 Mar 2021 21:44:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 826CC61A27 for ; Fri, 26 Mar 2021 21:44:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230194AbhCZVnf (ORCPT ); Fri, 26 Mar 2021 17:43:35 -0400 Received: from mga02.intel.com ([134.134.136.20]:19095 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229969AbhCZVnF (ORCPT ); Fri, 26 Mar 2021 17:43:05 -0400 IronPort-SDR: 6I8C7xiNI4hl0x0sMjkEfMFjh97pt4AAMix1MxNV6AED9P5D3Go6CaHRquU6ylhjDAXZuPIfqh gEtOkl7UnX2A== X-IronPort-AV: E=McAfee;i="6000,8403,9935"; a="178352800" X-IronPort-AV: E=Sophos;i="5.81,281,1610438400"; d="scan'208";a="178352800" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2021 14:42:59 -0700 IronPort-SDR: cNojrf+tiikCPGWgRb3ibY3Q/jovmS8uKWnJmBvLnZfc+CV7+xWZZ05N7eGLEjHmDUBPP/m7Xc U7ViBKcq2BbQ== X-IronPort-AV: E=Sophos;i="5.81,281,1610438400"; d="scan'208";a="437024048" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2021 14:42:51 -0700 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1lPuEA-00GV4K-I1; Fri, 26 Mar 2021 23:42:46 +0200 Date: Fri, 26 Mar 2021 23:42:46 +0200 From: Andy Shevchenko To: Bjorn Helgaas Cc: Heiner Kallweit , Bjorn Helgaas , Jonathan Corbet , Jens Axboe , Viresh Kumar , Dan Williams , Vinod Koul , David Miller , Lee Jones , Ion Badulescu , Jakub Kicinski , Lino Sanfilippo , Christian Lamparter , Kalle Valo , Luis Chamberlain , Adam Radford , "James E.J. Bottomley" , "Martin K. Petersen" , James Smart , Dick Kennedy , Nilesh Javali , GR-QLogic-Storage-Upstream@marvell.com, Greg Kroah-Hartman , Jiri Slaby , Peter Chen , Felipe Balbi , "linux-pci@vger.kernel.org" , linux-doc@vger.kernel.org, Linux Kernel Mailing List , linux-ide@vger.kernel.org, dmaengine@vger.kernel.org, "netdev@vger.kernel.org" , linux-parisc@vger.kernel.org, linux-wireless , SCSI development list , linux-serial@vger.kernel.org, Linux USB Mailing List , Randy Dunlap , Andrew Morton Subject: Re: [PATCH] PCI: Remove pci_try_set_mwi Message-ID: References: <4d535d35-6c8c-2bd8-812b-2b53194ce0ec@gmail.com> <20210326212655.GA912670@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210326212655.GA912670@bjorn-Precision-5520> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org On Fri, Mar 26, 2021 at 04:26:55PM -0500, Bjorn Helgaas wrote: > [+cc Randy, Andrew (though I'm sure you have zero interest in this > ancient question :))] > > On Wed, Dec 09, 2020 at 09:31:21AM +0100, Heiner Kallweit wrote: > > pci_set_mwi() and pci_try_set_mwi() do exactly the same, just that the > > former one is declared as __must_check. However also some callers of > > pci_set_mwi() have a comment that it's an optional feature. I don't > > think there's much sense in this separation and the use of > > __must_check. Therefore remove pci_try_set_mwi() and remove the > > __must_check attribute from pci_set_mwi(). > > I don't expect either function to be used in new code anyway. > > There's not much I like better than removing things. But some > significant thought went into adding pci_try_set_mwi() in the first > place, so I need a little more convincing about why it's safe to > remove it. > > The argument should cite the discussion about adding it. I think one > of the earliest conversations is here: > https://lore.kernel.org/linux-ide/20070404213704.224128ec.randy.dunlap@oracle.com/ It's solely PCI feature which is absent on PCIe. So, if there is a guarantee that the driver never services a device connected to old PCI bus, it's okay to remove the call (it's no-op on PCIe anyway). OTOH, PCI core may try MWI itself for every device (but this is an opposite, what should we do on broken devices that do change their state based on that bit while violating specification). In any case Acked-by: Andy Shevchenko for DesignWare DMA case. I have added that and I never saw that IP connected to the old PCI. -- With Best Regards, Andy Shevchenko