In article <yf9adm7ywvk.fsf@mc.pp.se>
marcus@mc.pp.se wrote:

> The macppc strategy seems pretty similar to what I had in mind, but
> rather than having a global function to create the bus_space_tags, all
> the possible variants (should be only 2 or 3 anyway) would be premade
> and provided through the attach_args.  The difference isn't great, but
> I think using attach_args rather than a global function provides
> better encapsulation (since only devices actually attached to the
> g2bus driver would be able to access the g2bus bus_space_tags).

If all devices are connected to g2bus directly, it's better
to handle them in attach_args for encapsulation.
But rtk on BbA is connected over gapspci ASIC and LAN adapter is
connected to g2bus directly, we can treat them at different busses.
For example, pcib.c for PCI-ISA bridge sets own bus space tag
for ISA devices.

> > Another possible way is to prepare independent bus space tag for gapspci.
> 
> I'm not quite sure what you mean here.  The gapspci driver doesn't
> need any special stride or anything, so there is no need to have a
> special tag for it.

Even if it requires no special functions, they should have
independent bus space tag if we assume it is different bus.
If BbA and Lan adapter has independent bus space tag,
it does not break encapsulation to have global functions to set
pointers. (g2bus_bus_mem_init() and gapspci_bus_mem_init() etc.)

Anyway, in this case, the difference between our two scheme is small
and it is just our liking, so the port maintainer should select it ;-)
We can rethink this when more complicated device is appeared.

> > needed for the devices. Anyway, it is actually  something like
> > bridge device (it also has ISA NE2000) so we might have to prepare
> > another bus space tag for it.
> 
> It should be a separate bus driver at least, so that ISA drivers can
> attach to it.  However, it might not need its own bus_space_tag.  Just
> creating bus_space_handles from the regular g2bus bus_space_tag and
> passing them to the driver(s) might work.

The ISA bridge on Ikehara's adapter has only minimum functions
to support wdc and ne2000. It cannot handle DMA and memory-mapped
access etc. so it could not use MI ISA drivers directly.

It is really similar with the "Neptune" adapter on x68k,
which is a bridge between ISA and x68k local bus:
http://www.amy.hi-ho.ne.jp/shimada/neptune/board.html
See neptune.c and if_ne_neptune.c under sys/arch/x68k/dev.
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp