Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1460869imu; Wed, 28 Nov 2018 09:52:51 -0800 (PST) X-Google-Smtp-Source: AFSGD/Vj/4Tv6DVMibsD2EmH/VKCONtqW53E4FJmrwiWBbmfXiEr65dsSprvkQXoa89Cf3mv0cEq X-Received: by 2002:a65:47ca:: with SMTP id f10mr34751531pgs.166.1543427571338; Wed, 28 Nov 2018 09:52:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543427571; cv=none; d=google.com; s=arc-20160816; b=AZJGQBTIE3Y9tevzIQjXGb1XcLd3OJb9Pm+dDicjmfx6zNnW3P4txL18jWB2dyiH6T NB7vo+1PhOKGOYXzZps1FU399CxtUy6xtbydJ/NTkZNtfGz4KgfVkCj0FcwJv+jpPDjW /nUmmxApru4OJK5a8efEtJ0HyLBgVZ+1SrWddIMjZlDPJf7QsZuZiE+dUk6fBH5WWtU7 QlwQ9A+m4m0oNEOUxozN4RgqZ7Saxqm1GJhIOIK5fFdyncOZDZuTa+zd73Ia2mNrfkwM NWgrJ2YFyJrOwOoo2/RCIHps9pvE3k7b3D60S8TJMh8UKZvP555rUWK61l6pIH7Qpz+s rd/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=JtV5jyDBtkXuP2CeZdOsoRQwV9kmOUagEhfah/zgxWU=; b=dkVEniJzne6zTSmuVK+l8AbvrBP6Zr6BlnKxn12q6dY1+JJWSni+ay4kqKqQNW7rPR x/8TVvzpT9Zn8TwnbgNgyxan2LzHAr8XzJuNuh+GegEU6Q7/cWgj+MbzvyULPOLJhoUh FKgM95rOjO+NSrdaQuCuC2Lzj4vzdWTR0z6JWIuyMPugqjH/rXRgVUDful8Q+vvS7h03 ynRPhvoH3Yqey6OxSx0d31rD8CTp4QxD/l1cmHM5XDyVCTZ3bI0WBkqeDODp89AII+8X MND6X6ruTRaDHhCRCz3d/qRA+x10DD8kE+mHW6B2gcNSEY4y8jFrdkD2kLvW+smfN1R6 MaxA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r6si8110540pli.248.2018.11.28.09.52.30; Wed, 28 Nov 2018 09:52:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729018AbeK2ExL (ORCPT + 99 others); Wed, 28 Nov 2018 23:53:11 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:46373 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727867AbeK2ExL (ORCPT ); Wed, 28 Nov 2018 23:53:11 -0500 Received: from kresse.hi.pengutronix.de ([2001:67c:670:100:1d::2a]) by metis.ext.pengutronix.de with esmtp (Exim 4.89) (envelope-from ) id 1gS3yy-0003VL-PR; Wed, 28 Nov 2018 18:50:40 +0100 Message-ID: <1543427438.2507.52.camel@pengutronix.de> Subject: Re: [PATCH v3 2/2] PCI: imx6: limit DBI register length From: Lucas Stach To: Stefan Agner , Leonard Crestez Cc: lorenzo.pieralisi@arm.com, Trent Piepho , Richard Zhu , linux-kernel@vger.kernel.org, jingoohan1@gmail.com, gustavo.pimentel@synopsys.com, andrew.smirnov@gmail.com, linux-pci@vger.kernel.org, bhelgaas@google.com Date: Wed, 28 Nov 2018 18:50:38 +0100 In-Reply-To: References: <20181120165626.26424-1-stefan@agner.ch> <20181120165626.26424-2-stefan@agner.ch> <581b9548043d5276f6685f534386180fd0673a9a.camel@nxp.com> <1542741198.30311.608.camel@impinj.com> <268e109e1c6b309454bd5a313078894c@agner.ch> <1542749302.30311.624.camel@impinj.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::2a X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Mittwoch, den 28.11.2018, 18:36 +0100 schrieb Stefan Agner: > On 28.11.2018 13:19, Stefan Agner wrote: > > On 21.11.2018 14:47, Leonard Crestez wrote: > > > On 11/20/2018 11:28 PM, Trent Piepho wrote: > > > > On Tue, 2018-11-20 at 21:42 +0100, Stefan Agner wrote: > > > > > On 20.11.2018 20:13, Trent Piepho wrote: > > > > > > It also seems to me that this doesn't need to be in the internal pci > > > > > > config access functions.  The driver shouldn't be reading registers > > > > > > that don't exist anyway.  It's really about trying to fix sysfs access > > > > > > to registers that don't exist.  So maybe it should be done there. > > > > > > > > > > That was my first approach, see: > > > > > > > > Yes, but that just used the pci device id which applies to every IMX > > > > design. > > > > > > > > It's also not totally correct, as it seems real registers after 0x200 > > > > do work on imx6, and that would prevent access to them. > > > > > > I see that Lorenzo already accepted the patch in pci/dwc: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git/commit/?h=pci/dwc&id=f14eaec153aaebbe940ddd21e4198cc2abc927c2 > > > > > > My tests show that this series breaks pci cards on 6qdl and I think it > > > should be reverted until a fix is found. Are you OK with this? > > > > > > Fixing might require an entirely different approach. > > > > I tried to reproduce this issue on Apalis iMX6 (i.MX 6Q) with a ath9k > > PCIe WiFi card, the issue you are seeing did not happen. My lspci looks > > as follows: > > > > root@ea210c63d739:/# lspci -v > > 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 > > [Normal decode]) > >         Flags: bus master, fast devsel, latency 0, IRQ 255 > >         Memory at 01000000 (32-bit, non-prefetchable) [size=1M] > >         Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0 > >         Memory behind bridge: 01100000-011fffff > >         [virtual] Expansion ROM at 01200000 [disabled] [size=64K] > >         Capabilities: [40] Power Management version 3 > >         Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ > >         Capabilities: [70] Express Root Port (Slot-), MSI 00 > >         Capabilities: [100] Advanced Error Reporting > >         Capabilities: [140] Virtual Channel > > lspci: Unable to load libkmod resources: error -12 > > > > 01:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network > > Adapter (PCI-Express) (rev 01) > >         Subsystem: Foxconn International, Inc. Device e007 > >         Flags: bus master, fast devsel, latency 0, IRQ 312 > >         Memory at 01100000 (64-bit, non-prefetchable) [size=64K] > >         Capabilities: [40] Power Management version 2 > >         Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- > >         Capabilities: [60] Express Legacy Endpoint, MSI 00 > >         Capabilities: [90] MSI-X: Enable- Count=1 Masked- > >         Capabilities: [100] Advanced Error Reporting > >         Capabilities: [140] Virtual Channel > >         Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 > >         Kernel driver in use: ath9k > > > > > > I did also setup a WiFi network and transmitted some packages, but I did > > not get a nobody carred message. Do you have an idea why that might be? > > > > # cat /proc/interrupts > > ... > > 312:      10967          0          0          0       GPC 123 Level     > > ath9k > > ... > > > > > > Your conclusion in this thread seem reasonable, hence reverting the > > issue does. However, I still would like to reproduce the issue so I can > > make sure that future patches don't break it :-) > > Hm, I realized that I need to enable CONFIG_PCIEPORTBUS and set > ath9k.use_msi=1 to get MSI for that card. However, it seems that ath9k > does not behave well in that setup. It does get interrupts, and seems to > work to some degree, but I was not successful in transmitting data over > WiFi, but that might be an entirly different thing. > > However, what I noticed is that when CONFIG_PCIEPORTBUS and > CONFIG_PCI_MSI is enabled, MSI works but legacy interrupt seem not to > fire anymore. That is true for ath9k as well as e1000e (using > e1000e.IntMode=0 to force legacy). Is that a known issue/limitation with > i.MX 6 PCIe? Yes, this is a known issue with the Designware PCIe core, not just on i.MX6. As soon as any MSI interrupt is enabled, the core doesn't forward legacy IRQs anymore. So if any card in your system needs legacy interrupts (and ath9k is very likely to need this, as MSI support is pretty new and experimental), you need to boot with "nomsi" set on the kernel command line. Regards, Lucas