Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp226284pxb; Fri, 15 Jan 2021 01:28:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJystfZW8KghSMEEFQ3WLlepbbpOU/HCEcUDSXF5U0g+AIkKHXxcd28nXwREcOsST6L1SVgX X-Received: by 2002:a17:906:4c55:: with SMTP id d21mr8257940ejw.116.1610702888966; Fri, 15 Jan 2021 01:28:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610702888; cv=none; d=google.com; s=arc-20160816; b=i6VqZpyGfkZnOv9T1V3rE2e+uAExZQ8QHE6E55PPT6MS6XDT/yCi/sGVax1UKt3oNc fqgqu8KBgU6T7O6wo32aQJlLKUhqAEK98Y5vkYLd4kujucozBA9ynbjQKbgmh86nHgwJ z/OJHFpZJPL9TjXcYmzCEpdjdHsGHLOy6K3lOCtDlXHnbGx5PRFEBAIrqpxCWT+qc32D /886SvswUIQdO2pX3hoGj2GaRkxVI82C0HdaErFMsb+j1YUZ5giB4AUkOONrO/rx8mbA uU5EZHRpPt0HJ0oKjcJo1sBz1bZ0tUS2om/UxG7JNZObBvZgJyrhCCEezWH/svfklj4a 6W6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=ws2F730VN2fbq90WuzsMpLC9UjZzVl4J3RF/sAqGHt4=; b=biDrH6xqFelWcyRduajkoz9UehUJPSFG4jiHQC2lHNvRCM/mSmozOPYp+cw9/XrbmI a6CAXY68RODrZZ8dlIUNC7mXP5vcrI9O/JE1/IGrmnVI9LKMyeU45XObQOrFz6VctG6U s7CynBs191m3Vm67iXwTyNtUiRL9qzW1iAcyn1V4pOrqTNko0elcI1CqUedYF+K4hCkY uKrTJUW7ZT4dOvXVmyKs0YLxJu9bDveaH1qpGR19cTrIIEmSCFt0zuGkBLe9yGZm4XSV Zq+tAqj9PVA5fSuY4hObGTBoRGv9lrRqROA/IrL+p6luR7so83DRni3mumv8bCiynKDa bdcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HF247d1c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c8si4327392edq.432.2021.01.15.01.27.45; Fri, 15 Jan 2021 01:28:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=HF247d1c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729208AbhAOJ0N (ORCPT + 99 others); Fri, 15 Jan 2021 04:26:13 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:28795 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726494AbhAOJ0M (ORCPT ); Fri, 15 Jan 2021 04:26:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610702685; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ws2F730VN2fbq90WuzsMpLC9UjZzVl4J3RF/sAqGHt4=; b=HF247d1cqOKHG4o7Ds6CLczCu5f1PoV2Tp3UYk9MpwKK+h9qOPx3nYx37PJ62xuAWGRjIO r6kn31pVh2iD9CvjKxxjcAYqq1CNAHkrKvluSu1xmvIjISoZuTEsUefq3gZNxThg387Ii6 /5xoHL06IHsWdeamKctCts0InjfMoRI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-182-R7ynSWHhPn2cHKelC4L-ew-1; Fri, 15 Jan 2021 04:24:43 -0500 X-MC-Unique: R7ynSWHhPn2cHKelC4L-ew-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7DE328464D4; Fri, 15 Jan 2021 09:24:41 +0000 (UTC) Received: from [10.36.114.165] (ovpn-114-165.ams2.redhat.com [10.36.114.165]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 52E316F922; Fri, 15 Jan 2021 09:24:35 +0000 (UTC) Subject: Re: [RFC v3 2/2] vfio/platform: msi: add Broadcom platform devices To: Vikas Gupta Cc: Alex Williamson , Cornelia Huck , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Vikram Prakash , Srinath Mannam , Ashwin Kamath , Zac Schroff , Manish Kurup References: <20201124161646.41191-1-vikas.gupta@broadcom.com> <20201214174514.22006-1-vikas.gupta@broadcom.com> <20201214174514.22006-3-vikas.gupta@broadcom.com> From: Auger Eric Message-ID: <25199e7e-4a42-c69a-0d16-4bf1764ee87b@redhat.com> Date: Fri, 15 Jan 2021 10:24:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vikas, On 1/15/21 7:35 AM, Vikas Gupta wrote: > Hi Eric, > > On Tue, Jan 12, 2021 at 2:52 PM Auger Eric wrote: >> >> Hi Vikas, >> >> On 12/14/20 6:45 PM, Vikas Gupta wrote: >>> Add msi support for Broadcom platform devices >>> >>> Signed-off-by: Vikas Gupta >>> --- >>> drivers/vfio/platform/Kconfig | 1 + >>> drivers/vfio/platform/Makefile | 1 + >>> drivers/vfio/platform/msi/Kconfig | 9 ++++ >>> drivers/vfio/platform/msi/Makefile | 2 + >>> .../vfio/platform/msi/vfio_platform_bcmplt.c | 49 +++++++++++++++++++ >>> 5 files changed, 62 insertions(+) >>> create mode 100644 drivers/vfio/platform/msi/Kconfig >>> create mode 100644 drivers/vfio/platform/msi/Makefile >>> create mode 100644 drivers/vfio/platform/msi/vfio_platform_bcmplt.c >> what does plt mean? > This(plt) is a generic name for Broadcom platform devices, which we`ll > plan to add in this file. Currently we have only one in this file. > Do you think this name does not sound good here? we have VFIO_PLATFORM_BCMFLEXRM_RESET config which also applied to vfio flex-rm platform device. I think it would be more homegenous to have VFIO_PLATFORM_BCMFLEXRM_MSI in case we keep a separate msi module. also in reset dir we have vfio_platform_bcmflexrm.c >>> >>> diff --git a/drivers/vfio/platform/Kconfig b/drivers/vfio/platform/Kconfig >>> index dc1a3c44f2c6..7b8696febe61 100644 >>> --- a/drivers/vfio/platform/Kconfig >>> +++ b/drivers/vfio/platform/Kconfig >>> @@ -21,3 +21,4 @@ config VFIO_AMBA >>> If you don't know what to do here, say N. >>> >>> source "drivers/vfio/platform/reset/Kconfig" >>> +source "drivers/vfio/platform/msi/Kconfig" >>> diff --git a/drivers/vfio/platform/Makefile b/drivers/vfio/platform/Makefile >>> index 3f3a24e7c4ef..9ccdcdbf0e7e 100644 >>> --- a/drivers/vfio/platform/Makefile >>> +++ b/drivers/vfio/platform/Makefile >>> @@ -5,6 +5,7 @@ vfio-platform-y := vfio_platform.o >>> obj-$(CONFIG_VFIO_PLATFORM) += vfio-platform.o >>> obj-$(CONFIG_VFIO_PLATFORM) += vfio-platform-base.o >>> obj-$(CONFIG_VFIO_PLATFORM) += reset/ >>> +obj-$(CONFIG_VFIO_PLATFORM) += msi/ >>> >>> vfio-amba-y := vfio_amba.o >>> >>> diff --git a/drivers/vfio/platform/msi/Kconfig b/drivers/vfio/platform/msi/Kconfig >>> new file mode 100644 >>> index 000000000000..54d6b70e1e32 >>> --- /dev/null >>> +++ b/drivers/vfio/platform/msi/Kconfig >>> @@ -0,0 +1,9 @@ >>> +# SPDX-License-Identifier: GPL-2.0-only >>> +config VFIO_PLATFORM_BCMPLT_MSI >>> + tristate "MSI support for Broadcom platform devices" >>> + depends on VFIO_PLATFORM && (ARCH_BCM_IPROC || COMPILE_TEST) >>> + default ARCH_BCM_IPROC >>> + help >>> + Enables the VFIO platform driver to handle msi for Broadcom devices >>> + >>> + If you don't know what to do here, say N. >>> diff --git a/drivers/vfio/platform/msi/Makefile b/drivers/vfio/platform/msi/Makefile >>> new file mode 100644 >>> index 000000000000..27422d45cecb >>> --- /dev/null >>> +++ b/drivers/vfio/platform/msi/Makefile >>> @@ -0,0 +1,2 @@ >>> +# SPDX-License-Identifier: GPL-2.0 >>> +obj-$(CONFIG_VFIO_PLATFORM_BCMPLT_MSI) += vfio_platform_bcmplt.o >>> diff --git a/drivers/vfio/platform/msi/vfio_platform_bcmplt.c b/drivers/vfio/platform/msi/vfio_platform_bcmplt.c >>> new file mode 100644 >>> index 000000000000..a074b5e92d77 >>> --- /dev/null >>> +++ b/drivers/vfio/platform/msi/vfio_platform_bcmplt.c >>> @@ -0,0 +1,49 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +/* >>> + * Copyright 2020 Broadcom. >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include "../vfio_platform_private.h" >>> + >>> +#define RING_SIZE (64 << 10) >>> + >>> +#define RING_MSI_ADDR_LS 0x03c >>> +#define RING_MSI_ADDR_MS 0x040 >>> +#define RING_MSI_DATA_VALUE 0x064 >> Those 3 defines would not be needed anymore with that implementation option. >>> + >>> +static u32 bcm_num_msi(struct vfio_platform_device *vdev) >>> +{ >>> + struct vfio_platform_region *reg = &vdev->regions[0]; >>> + >>> + return (reg->size / RING_SIZE); >>> +} >>> + >>> +static struct vfio_platform_msi_node vfio_platform_bcmflexrm_msi_node = { >>> + .owner = THIS_MODULE, >>> + .compat = "brcm,iproc-flexrm-mbox", >>> + .of_get_msi = bcm_num_msi, >>> +}; >>> + >>> +static int __init vfio_platform_bcmflexrm_msi_module_init(void) >>> +{ >>> + __vfio_platform_register_msi(&vfio_platform_bcmflexrm_msi_node); >>> + >>> + return 0; >>> +} >>> + >>> +static void __exit vfio_platform_bcmflexrm_msi_module_exit(void) >>> +{ >>> + vfio_platform_unregister_msi("brcm,iproc-flexrm-mbox"); >>> +} >>> + >>> +module_init(vfio_platform_bcmflexrm_msi_module_init); >>> +module_exit(vfio_platform_bcmflexrm_msi_module_exit); >> One thing I would like to discuss with Alex. >> >> As the reset module is mandated (except if reset_required is forced to >> 0), I am wondering if we shouldn't try to turn the reset module into a >> "specialization" module and put the msi hooks there. I am afraid we may >> end up having modules for each and every vfio platform feature >> specialization. At the moment that's fully bearable but I can't predict >> what's next. >> >> As the mandated feature is the reset capability maybe we could just keep >> the config/module name terminology, tune the kconfig help message to >> mention the msi support in case of flex-rm? >> > As I understand, your proposal is that we should not have a separate > module for MSI, rather we add in the existing reset module for > flex-rm. Thus, this way reset modules do not seem to be specialized > just for reset functionality only but for MSI as well. Apart from this > we need not to load the proposed msi module in this patch series. Is > my understanding correct? yes it is. > For me it looks OK to consolidate MSI in the existing 'reset' module. > Let me know your views so that I can work for the next patch set accordingly. Before you launch into the rewriting I would like to get the confirmation Alex is OK or if he prefers to keep separate modules. Thanks Eric > > Thanks, > Vikas > >> What do you think? >> >> Thanks >> >> Eric >> >> >> >> >>> + >>> +MODULE_LICENSE("GPL v2"); >>> +MODULE_AUTHOR("Broadcom"); >>> >>