From owner-svn-src-head@FreeBSD.ORG Sun Sep 28 07:27:59 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DBAAF57; Sun, 28 Sep 2014 07:27:59 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FF05DD6; Sun, 28 Sep 2014 07:27:59 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.9/8.14.9) with ESMTP id s8S7Rx11068696; Sun, 28 Sep 2014 07:27:59 GMT (envelope-from adrian@FreeBSD.org) Received: (from adrian@localhost) by svn.freebsd.org (8.14.9/8.14.9/Submit) id s8S7RxWP068695; Sun, 28 Sep 2014 07:27:59 GMT (envelope-from adrian@FreeBSD.org) Message-Id: <201409280727.s8S7RxWP068695@svn.freebsd.org> X-Authentication-Warning: svn.freebsd.org: adrian set sender to adrian@FreeBSD.org using -f From: Adrian Chadd Date: Sun, 28 Sep 2014 07:27:59 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r272239 - head/sys/mips/atheros X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 07:27:59 -0000 Author: adrian Date: Sun Sep 28 07:27:58 2014 New Revision: 272239 URL: http://svnweb.freebsd.org/changeset/base/272239 Log: Fix the AR724x PCIe glue to correctly probe the BAR on AR7240 devices. There's a bug in the AR7240 PCIe hardware where a correct BAR will end up having the device disappear. It turns out that for the device address it should be all 0's. However, this meant that the PCI probe code would try writing 0xffffffff in to see how big the window was, read back 0x0, and think the window was 32 bits. It then ended up calculating a resource size of 0 bytes, failed to find anything via an rman call, and this would fail to attach. I have quite absolutely no idea how in the various planes of existence this particular bit of code and how it worked with the PCI bus code ever worked. But, well, it did. Tested: * Atheros AP93 - AR7240 + AR9280 reference board Modified: head/sys/mips/atheros/ar724x_pci.c Modified: head/sys/mips/atheros/ar724x_pci.c ============================================================================== --- head/sys/mips/atheros/ar724x_pci.c Sun Sep 28 07:19:32 2014 (r272238) +++ head/sys/mips/atheros/ar724x_pci.c Sun Sep 28 07:27:58 2014 (r272239) @@ -159,10 +159,18 @@ ar724x_pci_write_config(device_t dev, u_ return; /* - * WAR for BAR issue on AR7240 - We are unable to access the PCI device - * space if we set the BAR with proper base address. + * WAR for BAR issue on AR7240 - We are unable to access the PCI + * device space if we set the BAR with proper base address. + * + * However, we _do_ want to allow programming in the probe value + * (0xffffffff) so the PCI code can find out how big the memory + * map is for this device. Without it, it'll think the memory + * map is 32 bits wide, the PCI code will then end up thinking + * the register window is '0' and fail to allocate resources. */ - if (reg == PCIR_BAR(0) && bytes == 4 && ar71xx_soc == AR71XX_SOC_AR7240) + if (reg == PCIR_BAR(0) && bytes == 4 + && ar71xx_soc == AR71XX_SOC_AR7240 + && data != 0xffffffff) ar724x_pci_write(AR724X_PCI_CFG_BASE, reg, 0xffff, bytes); else ar724x_pci_write(AR724X_PCI_CFG_BASE, reg, data, bytes);