All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Jan Beulich <JBeulich@novell.com>,
	mingo@elte.hu, tglx@linutronix.de, hpa@zytor.com,
	arozansk@redhat.com, Michal Marek <mmarek@suse.cz>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH, resend] x86/PCI: don't export a __devinit function
Date: Thu, 17 Feb 2011 22:12:18 -0200	[thread overview]
Message-ID: <4D5DB962.8020005@redhat.com> (raw)
In-Reply-To: <AANLkTi=SR-HsBuOA0V6GPtD4wY+s663_6TT9aJVVjjrK@mail.gmail.com>

Em 17-02-2011 21:12, Yinghai Lu escreveu:
> On Thu, Feb 17, 2011 at 10:12 AM, Mauro Carvalho Chehab
> <mchehab@redhat.com> wrote:
>> Em 17-02-2011 14:08, Jan Beulich escreveu:
>>> Exporting a __devinit function (pcibios_scan_specific_bus()) isn't
>>> correct. (Michal, any reason why modpost only warns about exported
>>> __init functions?) Short of being able to think of a better solution,
>>> and short of making the whole call tree (reaching into the arch-
>>> independent part of the PCI subsystem) non-__devinit, export the
>>> symbol only when HOTPLUG is enabled (which is always the case for non-
>>> expert configurations), use section mismatch avoidance annotations for
>>> that case (knowing that __devinit functions will not be discarded),
>>> and mark the symbol __devinit only in the !HOTPLUG case.
>>>
>>> Consequently, EDAC_I7CORE (consuming the export) then has to depend on
>>> HOTPLUG.
>>
>> Having the entire i7core_edac driver depending on HOTPLUG, just because
>> a few BIOSes want to hide the non-core PCI devices doesn't seem nice.
>> One alternative would be to enclose the code that needs this function
>> with #ifdef CONFIG_HOTPLUG.
>>
>>> A fundamental question of course if whether this driver has
>>> to use that function in the first place (i.e. whether it wouldn't be
>>> better to just remove the export) - the problem it tries to address
>>> happens on other systems too, but the PCI bus the devices in question
>>> live on isn't necessarily bus 255. For the affected system I have, the
>>> alternative approach is to set pcibios_last_bus from __pci_mmcfg_init()
>>> based on the highest bus number on segment 0 being covered by MCFG.
>>
>> I received a few days ago a report that some BIOSes that hide those
>> PCI devices also use a different address for the last bus (0x3f, instead
>> of 0xff). So, it seems that the better would be to use an alternative
>> way to retrieve the last bus.
> 
> just append "pci=lastbus=255" will get all those devices.

I know, but the better would be if this could be detected, instead of
relying on a modprobe parameter.

Cheers,
Mauro

  reply	other threads:[~2011-02-18  0:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-17 16:08 [PATCH, resend] x86/PCI: don't export a __devinit function Jan Beulich
2011-02-17 17:21 ` Yinghai Lu
2011-02-18  9:07   ` Jan Beulich
2011-02-17 18:12 ` Mauro Carvalho Chehab
2011-02-17 23:12   ` Yinghai Lu
2011-02-18  0:12     ` Mauro Carvalho Chehab [this message]
2011-02-18  9:12   ` Jan Beulich
2011-02-22 23:25     ` Jesse Barnes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D5DB962.8020005@redhat.com \
    --to=mchehab@redhat.com \
    --cc=JBeulich@novell.com \
    --cc=arozansk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mmarek@suse.cz \
    --cc=tglx@linutronix.de \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.