linux-kernel - Re: [BUG] Multiple definition of pcibios_max

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120207085838.GB889@n2100.arm.linux.org.uk>
Date:	Tue, 7 Feb 2012 08:58:38 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Myron Stowe <mstowe@...hat.com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Mike Rapoport <mike@...pulab.co.il>
Subject: Re: [BUG] Multiple definition of pcibios_max_latency

On Mon, Feb 06, 2012 at 10:59:17AM -0700, Myron Stowe wrote:
> On Sat, 2012-02-04 at 12:59 +0000, Russell King - ARM Linux wrote:
> > While building my test PXA configuration, I came across:
> > 
> > drivers/built-in.o:(.data+0x230): multiple definition of `pcibios_max_latency'
> > arch/arm/common/built-in.o:(.data+0x40c): first defined here
> > make[1]: *** [vmlinux.o] Error 1
> > 
> > This was introduced by:
> > 
> > commit 96c5590058d7fded14f43af2ab521436cecf3125
> > Author: Myron Stowe <mstowe@...hat.com>
> > Date:   Fri Oct 28 15:48:38 2011 -0600
> > 
> >     PCI: Pull PCI 'latency timer' setup up into the core
> > 
> >     The 'latency timer' of PCI devices, both Type 0 and Type 1,
> >     is setup in architecture-specific code [see: 'pcibios_set_master()'].
> >     There are two approaches being taken by all the architectures - check
> >     if the 'latency timer' is currently set between 16 and 255 and if not
> >     bring it within bounds, or, do nothing (and then there is the
> >     gratuitously different PA-RISC implementation).
> > 
> >     There is nothing architecture-specific about PCI's 'latency timer' so
> >     this patch pulls its setup functionality up into the PCI core by
> >     creating a generic 'pcibios_set_master()' function using the '__weak'
> >     attribute which can be used by all architectures as a default which,
> >     if necessary, can then be over-ridden by architecture-specific code.
> > 
> >     No functional change.
> > 
> >     Signed-off-by: Myron Stowe <myron.stowe@...hat.com>
> >     Signed-off-by: Jesse Barnes <jbarnes@...tuousgeek.org>
> > 
> > which moved the handling of pcibios_set_master() into core code for
> > everyone but ARM:
> > 
> >  arch/blackfin/include/asm/pci.h         |    4 ----
> >  arch/frv/mb93090-mb00/pci-frv.c         |    6 ------
> >  arch/frv/mb93090-mb00/pci-frv.h         |    2 --
> >  arch/h8300/include/asm/pci.h            |    5 -----
> >  arch/mips/pci/pci.c                     |    6 ------
> >  arch/mn10300/unit-asb2305/pci-asb2305.c |    6 ------
> >  arch/mn10300/unit-asb2305/pci-asb2305.h |    2 --
> >  arch/sh/drivers/pci/pci.c               |    6 ------
> >  arch/x86/include/asm/pci_x86.h          |    2 --
> >  arch/x86/pci/i386.c                     |    6 ------
> >  drivers/pci/pci.c                       |   29 +++++++++++++++++++++++++++++
> >  include/linux/pci.h                     |    3 +++
> >  12 files changed, 32 insertions(+), 45 deletions(-)
> > 
> > I think the right solution is to delete the (now duplicate) definition 
> > of pcibios_max_latency in arch/arm/common/it8152.c.  Please comment.
> 
> Yes, that commit is the culprit.  I was concerned about ARM in general
> when I posted this series as I do not have a compile environment for it,
> nor am I at all familiar with ARM to know if I had covered all the
> possible variations (i.e. 8152 vs other, non 8152 types).
> 
> Will deleting the 'pcibios_max_latency' definition in
> arch/arm/common/it8152.c be the correct solution for all ARM variations
> (I don't want to try and fix one while breaking others)?
> 
> I'll wait for your response/guidance and if this is the correct action
> generate a patch right away.

Well, we never get two PCI host bridges built into the same kernel, so
if you have an it8152 then you don't have anything of the others.

However, this is not my code, I don't know the platform, and I don't
know why it was added as part of this support in the first place.  That's
why Mike is on the CC list.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/