linux-mips
[Top] [All Lists]

Re: [PATCH 1/2] PCI: make pci_claim_resource() work with conflict resour

To: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
Subject: Re: [PATCH 1/2] PCI: make pci_claim_resource() work with conflict resources as appropriate
From: Bjorn Helgaas <bhelgaas@google.com>
Date: Thu, 28 Jul 2011 09:59:03 -0600
Cc: jbarnes@virtuousgeek.org, torvalds@linux-foundation.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, eyal@mips.com, zenon@mips.com, Ralf Baechle <ralph@linux-mips.org>
Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311872476; bh=VI5+wwD51qhtq8gMkNg7cYFjo44=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=aTTaUNuOaPpEDuw1QfCQRSnVqwPyu3XL71La5S4YcNBeOsPoWqW1WOHQbVWpR8JBo jFcCwBdTydKXbdaAQMYag==
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XVNRZb0erbzIalvoLFoIDETo2VvFq8TBS0AwG55h0cs=; b=wNRT96LnahjRQJlOnOWG6gkwWfNZjLZ29lhDIL3dwc5/dxi1Pg0Eg9SZ8XW93Sejbo CdFfoMpA4DKcrV3ZpCiw==
Domainkey-signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=rt2NDrUqN/NySWe4L9yPVe+IV6Bg8DGAffRMZqSQLF7fvZnYDpIMKzohp0hyBBxTY 1a4Kgoje2IjgBbi9GQclw==
In-reply-to: <1311852512-7340-2-git-send-email-dengcheng.zhu@gmail.com>
References: <1311852512-7340-1-git-send-email-dengcheng.zhu@gmail.com> <1311852512-7340-2-git-send-email-dengcheng.zhu@gmail.com>
Sender: linux-mips-bounce@linux-mips.org
On Thu, Jul 28, 2011 at 5:28 AM, Deng-Cheng Zhu <dengcheng.zhu@gmail.com> wrote:
> In resolving a network driver issue with the MIPS Malta platform, the root
> cause was traced into pci_claim_resource():
>
> MIPS System Controller's PCI I/O resources stay in 0x1000-0xffffff. When
> PCI quirks start claiming resources using request_resource_conflict(),
> collisions happen and -EBUSY is returned, thereby rendering the onboard AMD
> PCnet32 NIC unaware of quirks' region and preventing the NIC from functioning.
> For PCI quirks, PIIX4 ACPI is expected to claim 0x1000-0x103f, and PIIX4 SMB 
> to
> claim 0x1100-0x110f, both of which fall into the MSC I/O range. Certainly, we
> can increase the start point of this range in arch/mips/mti-malta/malta-pci.c 
> to
> avoid the collisions. But a fix in here looks more justified, though it seems 
> to
> have a wider impact. Using insert_xxx as opposed to request_xxx will register
> PCI quirks' resources as children of MSC I/O and return OK, instead of seeing
> collisions which are actually resolvable.

What's the collision?  Can we see the dmesg log (which should have
that information) and maybe the /proc/ioports contents?  Did something
change the order in which we claim resources, so things that used to
work now cause conflicts?

I think insert_resource() (where the newly-inserted resource can
become the parent of something that was previously inserted) is sort
of a hack, and the fact that we need it is telling us that we're doing
things in the wrong order.  It's nicer when we can discover and claim
resources in a top-down hierarchical way.  But I recognize that may
not always be possible, or at least not convenient.

Bjorn

<Prev in Thread] Current Thread [Next in Thread>