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 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.