From patchwork Tue Apr 8 12:36:32 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Willy Tarreau X-Patchwork-Id: 3950161 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1A1039F499 for ; Tue, 8 Apr 2014 17:46:16 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 27786203B5 for ; Tue, 8 Apr 2014 17:46:16 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D7745203AC for ; Tue, 8 Apr 2014 17:46:14 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WXXn3-0001IU-2C; Tue, 08 Apr 2014 15:18:21 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WXXmv-0004KM-0l; Tue, 08 Apr 2014 15:18:13 +0000 Received: from bombadil.infradead.org ([2001:1868:205::9]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WXXiU-0003gg-37 for linux-arm-kernel@merlin.infradead.org; Tue, 08 Apr 2014 15:13:38 +0000 Received: from 1wt.eu ([62.212.114.60]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WXVH3-00080w-G3 for linux-arm-kernel@lists.infradead.org; Tue, 08 Apr 2014 12:37:10 +0000 Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id s38CaWib010443; Tue, 8 Apr 2014 14:36:32 +0200 Date: Tue, 8 Apr 2014 14:36:32 +0200 From: Willy Tarreau To: Matthew Minter Subject: Re: Intel I350 mini-PCIe card (igb) on Mirabox (mvebu / Armada 370) Message-ID: <20140408123632.GG8767@1wt.eu> References: <20140406185833.GI29787@1wt.eu> <20140407174106.GD9952@obsidianresearch.com> <20140407204817.GB20736@obsidianresearch.com> <20140408064003.GU29787@1wt.eu> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140408_053710_099967_046F45D9 X-CRM114-Status: GOOD ( 11.60 ) X-Spam-Score: -0.3 (/) Cc: Neil Greatorex , Jason Gunthorpe , Thomas Petazzoni , linux-arm-kernel X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Matthew, On Tue, Apr 08, 2014 at 01:31:48PM +0100, Matthew Minter wrote: > To add to my previous point, I would consider releasing these patches > as soon as possible as it seems that it can easily cause panics on a > range of boards. Failing that perhaps it is at least worth releasing a > hotfix which will cause PCI probing to fail should the window not be a > power of two? Thus it will fail early with a warning instead of > potentially causing a kernel crash. Have you tested the whole patch or just the one enforcing the power of 2 ? It would be interesting to know if the one with SZ_4M is needed for you or not (I guess not). I suspect that just this single-liner will work as well, as it does for me. Thanks, Willy diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c index 0e79665..552ab73 100644 --- a/drivers/pci/host/pci-mvebu.c +++ b/drivers/pci/host/pci-mvebu.c @@ -363,6 +363,7 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port) port->memwin_size = (((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) - port->memwin_base; + port->memwin_size = roundup_pow_of_two(port->memwin_size); mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr, port->memwin_base, port->memwin_size);