From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751056AbcEDNJd (ORCPT ); Wed, 4 May 2016 09:09:33 -0400 Received: from ni.piap.pl ([195.187.100.4]:60697 "EHLO ni.piap.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750714AbcEDNJb (ORCPT ); Wed, 4 May 2016 09:09:31 -0400 From: khalasa@piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=) To: Bjorn Helgaas Cc: Bjorn Helgaas , Arnd Bergmann , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH REPOST] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA. References: <20160421154234.GB32739@localhost> <20160502165322.GC24851@localhost> Date: Wed, 04 May 2016 15:09:27 +0200 In-Reply-To: <20160502165322.GC24851@localhost> (Bjorn Helgaas's message of "Mon, 2 May 2016 11:53:22 -0500") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 95815 [May 04 2016] X-KLMS-AntiSpam-Version: 5.5.9.33 X-KLMS-AntiSpam-Envelope-From: khalasa@piap.pl X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 4108210, 4108247, 4108238 X-KLMS-AntiSpam-Info: LuaCore: 446 446 88ec50d27487793c09e74475af7a9455195c174b, Auth:dkim=none X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/05/04 10:22:50 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2016/05/04 07:19:00 #7575786 X-KLMS-AntiVirus-Status: Clean, skipped Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Bjorn Helgaas writes: > It looks like 498a92d42596 merely fixed a warning, at the expense of > breaking DMA on Cavium. Reverting it would bring the warning back, but > that's better than broken DMA. Perhaps we should change PCIE_BUS_PEER2PEER to also write MRRS anyway. I realize the CNS3xxx patch is some sort of clever workaround, and that PCIE_BUS_PEER2PEER (which normally comes from kernel command line parameter "pcie_bus_peer2peer") was not exactly intended for this. But if one asks for "peer2peer" (which means limiting transfers to 128 bytes), how could it all work if the bus mastering read requests are not equally limited? BTW s/MRSS/MRRS/g -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland