shige@NetBSD.org wrote:

> 1) Do we need to change the name of 'pchb' or not?

I prefer to have some other name, but I don't think it's so
important because we can rename it later and it should be trivial.
(unless we like to have (mostly noop) pchb attachment at pci)

> 2) Do we need to skip probing a PCI end of 'pchb' or not?

I don't see any reason to bother to skip it,
i.e. isn't "not configured" enough?
Is there any real problem like Allen said on the PLB-PCI bridge?

> > 1. we need to make an arrangement for a pchb driver.
> >    ibm4xx/pci/pchb.c + ibm4xx/pci/pci_machdep.c + ibm4xx/dev/ibm405gp.c
> >     -> ibm4xx/dev/pchb.c

With a quick grance, it seems okay to merge current ibm4xx/pci/pchb.c
and ibm4xx/pci/pci_machdep.c, but I'm not sure whether ibm405gp.c
could be merged.
How can we handle any ibm405gp (or other cpu) specific stuff
in a merged source?

> > 2. we need to tell pchb.c driver some configurations
> >    (#defines with IBM405GP_ in *.c) by another way.

Do you say about pcicfg_tag in current ibm405gp.c?
If pcicfg_tag is the only 405gp specific stuff in ibm405gp.c,
we could change ibm4xx_setup_pci() to take some arguments
to specify pcicfg_tag (or some other CPU or machine
dependent values).

> > 3. we need to reconsider about machine dependent pci function.
> >    What (pci_) functions shoud be in evbppc/<mach>/*.c?
> >    pci_intr_map() and pci_conf_interrupt() had been already moved.

If we should have multiple pci(9) implementation in a single port,
we can define pci_*(9) functions as macros which use indirect call
with pci_chipset_tag_t in include/pci_machdep.h. In this case,
all pci(9) functions could be in chipset dependent files.
(see alpha/include/pci_machdep.h and alpha/pci/*.c)

I guess interrupt stuff and conf_hook might be machine (board)
specific and configuration read/write stuff (with tag/dev/func etc.)
might be chipset dependent, but I think it's better to summarize
what variants (chipset/board combinations) we would have among
all ibm4xx ports.

> > 4. Is some global variables related bus_space_* ugly? or reasonable?
> >    Should they be in pci_chipset_tag_t (struct ibm4xx_pci_chipset) ?
> >    If need, define pchb_softc included pci_chipset_tag_t ?

I'm not sure what is your actual concern, but some bus_space_*
values are required before autoconf(9) is started (to initialize
console devices for example), so we can't allocate all of them in
softc and it's okay to have some globals in that case.
Once after autoconf(9) is started, we can put bus_space_* values
(maybe they are pointers) to the globals into softc or
pci_chipset_tag_t etc, though.

Anyway, it isn't easy to clean up all stuff at once,
so it's better to leave cosmetics/trivial part for now, IMO.
---
Izumi Tsutsui