Izumi Tsutsui <tsutsui@ceres.dti.ne.jp> writes:

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

Actually, I expect the LAN adapter hardware has the same hardware
structure as the BBA; i.e.  <standard chip> --> <glue chip> --> g2bus
Since the g2bus is serial, all devices using off-the-shelf components
also include a glue chip of some kind.  In the case of BBA, it's the
GAPSPCI glue chip.  The LAN adapater has a different glue chip, which
needs a different driver (it might be the same glue chip as in the
modem, but I don't know).

So for encapuslation, devices which are connected through such a glue
chip should not get a bus space directly from the g2bus driver, but
rather the glue chip bus driver gets the tag from the g2bus driver in
its attach_args, and then it creates a bus space for the device which
may be passed to the actual device driver through _its_ attach_args.

In the case of gapspci, this is done implicitly:  The gapspci driver
creates bus spaces for the device using the tag it gets from g2bus,
but it doesn't actually pass them to the driver, but instead passes a
pci_tag and a dma_tag, which the driver uses to access the hardware
registers and memory space.  But that's just because that's how the
generic PCI driver interface looks like.  If the driver had needed
direct access to the bus_space_handle, it could have been passed in
the attach_args.  Of course, only the corresponding bus_space_tag
should be passed to the actual driver, not all the tags offered by
g2bus to the glue chip driver.


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

It might be a question of NetBSD design philosophy as well.  But given
the small number of devices, it's simple enough to change the
implementation later of course.  :-)


  // Marcus