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=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 2A336C6377D for ; Thu, 22 Jul 2021 07:48:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 090CA61351 for ; Thu, 22 Jul 2021 07:48:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230090AbhGVHIK (ORCPT ); Thu, 22 Jul 2021 03:08:10 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]:3445 "EHLO frasgout.his.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229547AbhGVHIK (ORCPT ); Thu, 22 Jul 2021 03:08:10 -0400 Received: from fraeml737-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GVkhy5rnBz6D94x; Thu, 22 Jul 2021 15:33:54 +0800 (CST) Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by fraeml737-chm.china.huawei.com (10.206.15.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 22 Jul 2021 09:48:43 +0200 Received: from [10.47.26.161] (10.47.26.161) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Thu, 22 Jul 2021 08:48:42 +0100 Subject: Re: [PATCH V4 1/3] driver core: mark device as irq affinity managed if any irq is managed To: Thomas Gleixner , Christoph Hellwig CC: Ming Lei , Jens Axboe , , , "Greg Kroah-Hartman" , Bjorn Helgaas , , Sagi Grimberg , Daniel Wagner , Wen Xiong , Hannes Reinecke , Keith Busch , Marc Zyngier References: <20210715120844.636968-1-ming.lei@redhat.com> <20210715120844.636968-2-ming.lei@redhat.com> <5e534fdc-909e-39b2-521d-31f643a10558@huawei.com> <20210719094414.GC431@lst.de> <87lf60cevz.ffs@nanos.tec.linutronix.de> <20210721072445.GA11257@lst.de> <87y29zpgct.ffs@nanos.tec.linutronix.de> From: John Garry Message-ID: <27cf7c97-6b03-d1fd-7bfc-6aaf3cd50272@huawei.com> Date: Thu, 22 Jul 2021 08:48:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <87y29zpgct.ffs@nanos.tec.linutronix.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.47.26.161] X-ClientProxiedBy: lhreml706-chm.china.huawei.com (10.201.108.55) To lhreml724-chm.china.huawei.com (10.201.108.75) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On 21/07/2021 21:22, Thomas Gleixner wrote: >>> That's what I assumed, but this text from John suggested there is >>> something odd about the platform case: >>> >>> "Did you consider that for PCI .." >>> . >> For this special platform MSI case there is a secondary interrupt >> controller (called mbigen) which generates the MSI on behalf of the >> device, which I think the MSI belongs to (and not the device, itself). > MBIGEN is a different story because it converts wired interrupts into > MSI interrupts, IOW a MSI based interrupt pin extender. > > I might be wrong, but I seriously doubt that any multiqueue device which > wants to use affinity managed interrupts is built on top of that. Actually the SCSI device for which platform device managed interrupts support was added in commit e15f2fa959f2 uses mbigen. Thanks, John