From patchwork Fri Oct 19 15:53:02 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andreas Puhm X-Patchwork-Id: 10649709 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id C373E15E2 for ; Fri, 19 Oct 2018 15:59:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B0D7D280FC for ; Fri, 19 Oct 2018 15:59:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A4BA328113; Fri, 19 Oct 2018 15:59:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B19B4280FC for ; Fri, 19 Oct 2018 15:59:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727549AbeJTAFw convert rfc822-to-8bit (ORCPT ); Fri, 19 Oct 2018 20:05:52 -0400 Received: from mx01.busymouse24.de ([83.246.107.19]:53149 "EHLO mx01.busymouse24.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727010AbeJTAFw (ORCPT ); Fri, 19 Oct 2018 20:05:52 -0400 X-Greylist: delayed 365 seconds by postgrey-1.27 at vger.kernel.org; Fri, 19 Oct 2018 20:05:50 EDT Received: from maskedhost [127.0.0.1] by mx01.busymouse24.de stage1 with esmtps (Exim MailCleaner) id 1gDX5D-0008k6-Ny from ; Fri, 19 Oct 2018 17:53:03 +0200 Received: from SRV188.busymouse24.de (192.168.100.188) by SRV177.busymouse24.de (192.168.100.177) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 19 Oct 2018 17:53:03 +0200 Received: from SRV177.busymouse24.de (192.168.100.177) by SRV188.busymouse24.de (192.168.100.188) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 19 Oct 2018 17:53:02 +0200 Received: from SRV177.busymouse24.de ([fe80::f87a:2c8c:90ef:d29a]) by SRV177.busymouse24.de ([fe80::f87a:2c8c:90ef:d29a%14]) with mapi id 15.00.1263.000; Fri, 19 Oct 2018 17:53:02 +0200 From: Andreas Puhm To: Alan Tull , Moritz Fischer CC: "linux-fpga@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: [Bug] altera_cvp registers a PCI device (Altera/Intel FPGA) without verifying that it supports CVP Thread-Topic: [Bug] altera_cvp registers a PCI device (Altera/Intel FPGA) without verifying that it supports CVP Thread-Index: AdRnw6sLsfLCE4NLQri3QW4UMzXDuw== Date: Fri, 19 Oct 2018 15:53:02 +0000 Message-ID: <2c6313a3f7c04b70b8a06a50934fe27a@SRV177.busymouse24.de> Accept-Language: de-AT, de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [83.246.107.135] x-exclaimer-md-config: 1802f3fe-bc94-4301-9dc2-d59a74e6de3a MIME-Version: 1.0 Sender: linux-fpga-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fpga@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hello, I hope the following information is descriptive enough. If this is no the case, I will provide further details. -------------------------------------------------------------------- Full description: The altera_cvp probe function only checks, if the Altera/Intel PCI device configuration space contains a vendor specific entry (VSEC Capability Header 0x000b) at offset 0x200. But the probe function does not verify, if the PCI device (and further the FPGA), for which it has been called, actually supports the Configure-via-Protocol feature. The PCI device (FPGA) can explicitly disable the Configur-via-Protocol (CvP) feature by setting the CVP_EN bit, index 20 of CVP_STATUS register, to '0'. As the altera_cvp probe function does not check this it registers the device in any way. At this point, the altera_cvp module cannot be used to program this device via CvP. In addition no other module can use the device, as it is still registered by altera_cvp. Keywords: altera_cvp module, PCI, Configure-via-Protocol Kernel version: problem occured with v4.15, should occur from 4.14+ Instructions to reproduce: Proper hardware is necessary to reproduce this, i.e., FPGA with instantiated Altera/Intel PCIe IP Core with disabled CvP feature. Workaround: It is possible to circumvent this problem by manually unloading or blacklisting the altera_cvp module. Suggested Patch: This patch was successfully build and tested for 4.15 and 4.18 Subject: [PATCH] register device only, if it supports CvP operation This patch is based on: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tag/?h=v4.18 Signed-off-by: Andreas Puhm --- drivers/fpga/altera-cvp.c | 9 +++++++++ 1 file changed, 9 insertions(+) -- With best regards, Andreas Puhm diff --git a/drivers/fpga/altera-cvp.c b/drivers/fpga/altera-cvp.c index 7fa793672a7a..838abcfca0fb 100644 --- a/drivers/fpga/altera-cvp.c +++ b/drivers/fpga/altera-cvp.c @@ -403,6 +403,7 @@ static int altera_cvp_probe(struct pci_dev *pdev, struct altera_cvp_conf *conf; struct fpga_manager *mgr; u16 cmd, val; + u32 val32; int ret; /* @@ -416,6 +417,14 @@ static int altera_cvp_probe(struct pci_dev *pdev, return -ENODEV; } + pci_read_config_dword(pdev, VSE_CVP_STATUS, &val32); + if (!(val32 & VSE_CVP_STATUS_CVP_EN)) { + dev_err(&pdev->dev, + "CVP is disabled for this device: CVP_STATUS Reg 0x%x\n", + val32); + return -ENODEV; + } + conf = devm_kzalloc(&pdev->dev, sizeof(*conf), GFP_KERNEL); if (!conf) return -ENOMEM;