linux-mips
[Top] [All Lists]

Re: [PATCH] OF: PCI: const usage needed by MIPS

To: John Crispin <blogic@openwrt.org>
Subject: Re: [PATCH] OF: PCI: const usage needed by MIPS
From: Bjorn Helgaas <bhelgaas@google.com>
Date: Mon, 7 May 2012 08:11:08 -0700
Cc: David Daney <ddaney.cavm@gmail.com>, Ralf Baechle <ralf@linux-mips.org>, Grant Likely <grant.likely@secretlab.ca>, linux-pci@vger.kernel.org, devicetree-discuss@lists.ozlabs.org, linux-mips@linux-mips.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=6Wl6hVcAD/X4k+4T2wD3D0ZvUgFg32w7GYq3Bs3XCQ0=; b=ZwtSnz47ERv3KknxH4f3NPOoFJkLYW/aK6HPHKOSTmdbSStPAb1P2sOJsy3/2GrFOD d7o1Uq/26d9GefP3AX21Gse1F/zYlL6TnS52HdtC55XsXBjX9GQeHycFuqgMgwHj6bFH 76Y0Fn4lknF1SqlBfAw5L0y/SMaSgscY9h+aoD3J2DSO0+YOQEmsmrj9/qN3AdwgjM4l iocN4uhoMBA90GqT4fRVbkstU6PdAlY8m6No/+AwawMTm+2JPNvEj+ryGStiVKxQJIHf EplcZQMHQn9jJBHOk4xAQ+9jiG1VaABgOAB+A196Zc2H6il4TL5t/5i8HuRWc0E4QRPZ 4Q0Q==
In-reply-to: <4FA3B596.3050106@openwrt.org>
References: <1335808019-24502-1-git-send-email-blogic@openwrt.org> <4F9ED1DC.3050007@gmail.com> <4F9FE4F6.5070909@openwrt.org> <CAErSpo4bZ=0=DtbDots_GOGeLNhX6Q4eJrdetaFQMv4iiv5+XA@mail.gmail.com> <4FA32E47.7020406@gmail.com> <4FA3B596.3050106@openwrt.org>
Sender: linux-mips-bounce@linux-mips.org
On Fri, May 4, 2012 at 3:55 AM, John Crispin <blogic@openwrt.org> wrote:
> Hi David,
>
>> The problem is when you start declaring function pointers in various
>> ops vectors.
>>
>> Consider:
>>
>> void (*foo)(const struct pci_dev *)
>> void (*bar)(struct pci_dev *)
>>
>> foo and bar are not type compatible, and you will get compiler
>> warnings if you use one where the other is expected.

Oh, right.  I vaguely remember tripping over this a few years ago when
I refactored pci_swizzle_interrupt_pin().  Thanks for enhancing my
simple understanding.

>> So the question is:  Are we ever going to the address of any of the
>> functions that are being modified?  If so, we have created a problem.
>
> i could not find any place in the code where this happens, which does
> not mean that there are none.

I compiled alpha, ia64, mips, parisc, powerpc, sh, sparc, and x86 and
didn't see any issues related to this patch.  There might still be
something,  but I'm willing to help work through them or revert this
if it turns out to be a problem.  I'm still assuming that Grant will
handle this.

Bjorn

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