From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757408AbZKDROM (ORCPT ); Wed, 4 Nov 2009 12:14:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757149AbZKDROL (ORCPT ); Wed, 4 Nov 2009 12:14:11 -0500 Received: from outbound-mail-135.bluehost.com ([67.222.39.25]:53058 "HELO outbound-mail-135.bluehost.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1757063AbZKDROK (ORCPT ); Wed, 4 Nov 2009 12:14:10 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=virtuousgeek.org; h=Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=QmLY0C13KvpNkjBFXf+sq7dOLVI3ND6o51E0rpw/hYyWtLh6IjmG+sUatWF7MjRg8kG9ZijYRvIWw3m43CuzUO471Sh+x+jzsY6D2tbc0oyX5+ucWmdDAASm3KAt9YR0; Date: Wed, 4 Nov 2009 09:14:12 -0800 From: Jesse Barnes To: "Michael S. Tsirkin" Cc: Alex Chiang , Yu Zhao , Matthew Wilcox , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, gleb@redhat.com Subject: Re: [PATCH] pci: fix nit in ROM BAR size probing Message-ID: <20091104091412.50bb08d7@jbarnes-piketon> In-Reply-To: <20091104170550.GA506@redhat.com> References: <20091029152459.GA5480@redhat.com> <20091104090409.496540a1@jbarnes-piketon> <20091104170550.GA506@redhat.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.18.3; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Identified-User: {10642:box514.bluehost.com:virtuous:virtuousgeek.org} {sentby:smtp auth 75.111.28.251 authed with jbarnes@virtuousgeek.org} Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 4 Nov 2009 19:06:19 +0200 "Michael S. Tsirkin" wrote: > On Wed, Nov 04, 2009 at 09:04:09AM -0800, Jesse Barnes wrote: > > On Thu, 29 Oct 2009 17:24:59 +0200 > > "Michael S. Tsirkin" wrote: > > > > > When probing for ROM BAR size, we should not > > > change bits 1:10 in this BAR, because these > > > bits are marked as "reserved for future use" in PCI spec, > > > so changing them might have side effects. > > > > > > No such issue for I/O or memory, as there is > > > an implementation note in PCI spec which explicitly allows > > > writing 0xfffffffff there. > > > > > > Signed-off-by: Michael S. Tsirkin > > > --- > > > drivers/pci/probe.c | 4 ++-- > > > 1 files changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > > > index 8105e32..d65aae4 100644 > > > --- a/drivers/pci/probe.c > > > +++ b/drivers/pci/probe.c > > > @@ -163,12 +163,12 @@ int __pci_read_base(struct pci_dev *dev, > > > enum pci_bar_type type, { > > > u32 l, sz, mask; > > > > > > - mask = type ? ~PCI_ROM_ADDRESS_ENABLE : ~0; > > > + mask = type ? PCI_ROM_ADDRESS_MASK : ~0; > > > > > > res->name = pci_name(dev); > > > > > > pci_read_config_dword(dev, pos, &l); > > > - pci_write_config_dword(dev, pos, mask); > > > + pci_write_config_dword(dev, pos, l | mask); > > > pci_read_config_dword(dev, pos, &sz); > > > pci_write_config_dword(dev, pos, l); > > > > Applied to linux-next, thanks. Another possible enhancement here > > would be to make the mask into a switch based on the type, since > > mem32 and mem64 "BARs" (added by willy for doing BAR-like stuff) > > could probably use ~0 as well. > > > > Jesse > > Where can I find the patch by willy that adds these? commit 6ac665c63dcac8fcec534a1d224ecbb8b867ad59 Author: Matthew Wilcox Date: Mon Jul 28 13:38:59 2008 -0400 PCI: rewrite PCI BAR reading code -- Jesse Barnes, Intel Open Source Technology Center