From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: ppc-dev <linuxppc-dev@ozlabs.org>, paulus@samba.org
Subject: Re: [PATCH 3/7] [POWERPC] modify PCI code for a merged kernel
Date: Wed, 04 Oct 2006 18:02:37 +1000 [thread overview]
Message-ID: <1159948957.13323.80.camel@localhost.localdomain> (raw)
In-Reply-To: <20060926133651.897ad602.sfr@canb.auug.org.au>
On Tue, 2006-09-26 at 13:36 +1000, Stephen Rothwell wrote:
> -#ifndef CONFIG_PPC_ISERIES
> void __devinit pcibios_claim_one_bus(struct pci_bus *b)
> {
> struct pci_dev *dev;
> @@ -238,10 +238,12 @@ static void __init pcibios_claim_of_setu
> {
> struct pci_bus *b;
>
> + if (firmware_has_feature(FW_FEATURE_ISERIES))
> + return;
> +
> list_for_each_entry(b, &pci_root_buses, node)
> pcibios_claim_one_bus(b);
> }
> -#endif
Is the above actually needed ? That is, what kind of problem iseries
would expect if pcibios_claim_one_bus() was called ?
> #ifdef CONFIG_PPC_MULTIPLATFORM
> static u32 get_int_prop(struct device_node *np, const char *name, u32 def)
> @@ -554,9 +556,8 @@ static int __init pcibios_init(void)
> */
> ppc_md.phys_mem_access_prot = pci_phys_mem_access_prot;
>
> -#ifdef CONFIG_PPC_ISERIES
> - iSeries_pcibios_init();
> -#endif
> + if (firmware_has_feature(FW_FEATURE_ISERIES))
> + iSeries_pcibios_init();
Why not do like all other platforms and allocate create the PHBs
setup_arch ? That would avoid an iSeries specific call in generic code.
> printk(KERN_DEBUG "PCI: Probing PCI hardware\n");
>
> @@ -566,15 +567,15 @@ #endif
> pci_bus_add_devices(hose->bus);
> }
>
> -#ifndef CONFIG_PPC_ISERIES
> - if (pci_probe_only)
> - pcibios_claim_of_setup();
> - else
> - /* FIXME: `else' will be removed when
> - pci_assign_unassigned_resources() is able to work
> - correctly with [partially] allocated PCI tree. */
> - pci_assign_unassigned_resources();
> -#endif /* !CONFIG_PPC_ISERIES */
> + if (!firmware_has_feature(FW_FEATURE_ISERIES)) {
> + if (pci_probe_only)
> + pcibios_claim_of_setup();
> + else
> + /* FIXME: `else' will be removed when
> + pci_assign_unassigned_resources() is able to work
> + correctly with [partially] allocated PCI tree. */
> + pci_assign_unassigned_resources();
> + }
What happens if you don't do the above and set pci_probe_only to 1 ?
> /* Call machine dependent final fixup */
> if (ppc_md.pcibios_fixup)
> @@ -586,8 +587,9 @@ #endif /* !CONFIG_PPC_ISERIES */
> printk(KERN_DEBUG "ISA bridge at %s\n", pci_name(ppc64_isabridge_dev));
>
> #ifdef CONFIG_PPC_MULTIPLATFORM
> - /* map in PCI I/O space */
> - phbs_remap_io();
> + if (!firmware_has_feature(FW_FEATURE_ISERIES))
> + /* map in PCI I/O space */
> + phbs_remap_io();
> #endif
IO space mapping is dodgy with iSeries... I suppose that is correct for
now though we might want to do something a bit nastier like actually
mapping it to unaccessible memory and SEGV'ing on access or stuff like
that if IO is really not supported....
> printk(KERN_DEBUG "PCI: Probing PCI hardware done\n");
> @@ -637,13 +639,13 @@ int pcibios_enable_device(struct pci_dev
> */
> int pci_domain_nr(struct pci_bus *bus)
> {
> -#ifdef CONFIG_PPC_ISERIES
> - return 0;
> -#else
> - struct pci_controller *hose = pci_bus_to_host(bus);
> + if (firmware_has_feature(FW_FEATURE_ISERIES))
> + return 0;
> + else {
> + struct pci_controller *hose = pci_bus_to_host(bus);
>
> - return hose->global_number;
> -#endif
> + return hose->global_number;
> + }
> }
Any reason why the above is useful at all ? Especially since it seems
you -can- have multiple busses and thus -want- the domain numbers to be
exposed.
> EXPORT_SYMBOL(pci_domain_nr);
> @@ -651,12 +653,12 @@ EXPORT_SYMBOL(pci_domain_nr);
> /* Decide whether to display the domain number in /proc */
> int pci_proc_domain(struct pci_bus *bus)
> {
> -#ifdef CONFIG_PPC_ISERIES
> - return 0;
> -#else
> - struct pci_controller *hose = pci_bus_to_host(bus);
> - return hose->buid;
> -#endif
> + if (firmware_has_feature(FW_FEATURE_ISERIES))
> + return 0;
> + else {
> + struct pci_controller *hose = pci_bus_to_host(bus);
> + return hose->buid;
> + }
> }
Same question. Why do that at all ?
Cheers,
Ben.
next prev parent reply other threads:[~2006-10-04 8:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-26 3:34 [PATCH 1/7] [POWERPC] iSeries: set FW_FEATURE_ISERIES earlier Stephen Rothwell
2006-09-26 3:35 ` [PATCH 2/7] [POWERPC] The two vio HVC backends clash Stephen Rothwell
2006-09-26 3:36 ` [PATCH 3/7] [POWERPC] modify PCI code for a merged kernel Stephen Rothwell
2006-09-26 3:37 ` [PATCH 4/7] [POWERPC] fix ioremap for a combined kernel Stephen Rothwell
2006-09-26 3:39 ` [PATCH 5/7] [POWERPC] Allow combined iSeries and MULTIPLATFORM build Stephen Rothwell
2006-09-26 3:40 ` [PATCH 6/7] [POWERPC] iSeries does not need pcibios_fixup_resources Stephen Rothwell
2006-09-26 3:42 ` [PATCH 7/7] [POWERPC] implement BEGIN/END_FW_FTR_SECTION Stephen Rothwell
2006-10-04 7:58 ` Benjamin Herrenschmidt
2006-10-04 8:26 ` Stephen Rothwell
2006-10-04 10:08 ` Benjamin Herrenschmidt
2006-10-02 10:25 ` [PATCH 5/7] [POWERPC] Allow combined iSeries and MULTIPLATFORM build Paul Mackerras
2006-10-04 4:58 ` Stephen Rothwell
2006-10-04 8:02 ` Benjamin Herrenschmidt [this message]
2006-09-26 5:10 ` [PATCH 2/7] [POWERPC] The two vio HVC backends clash Olof Johansson
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=1159948957.13323.80.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=sfr@canb.auug.org.au \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).