Subject: Re: issues with com and non-PCI platforms.... a proposal
To: None <tech-kern@NetBSD.org>
From: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
List: tech-kern
Date: 03/08/2006 11:57:26
On Wed, Mar 08, 2006 at 10:47:44AM +0000, Steve Woodford wrote:
> On Tuesday 07 March 2006 03:13, Garrett D'Amore wrote:
> 
> >     2) use a separate bus space.  I don't know of any existing
> > examples outside of my AR5212 com driver.  In this case I had to
> > implement a pretty hefty amount of bus space logic *in com_arbus.c". 
> > This seems ugly and unwieldy.
> 
> It's also one of the only ways to go.
> 
> > #define   GETREG(x)   bus_space_read_1(bst, bsh, sc_regoffs[x])
> 
> If the underlying bus does not support byte-wise read/writes, this'll 
> still have to bounce through a bus_space(9) shim layer. I've worked with 
> hardware which supports 32-bit access only to those registers, for 
> example.
> 
> Perhaps a compromise is called for. Add some accessor function pointers 
> to com_softc, to be filled in by the bus-specific code.

Uhm - in my book, those accessor functions are called bus_space_read_foo()!
I don't like every other port to be penalized on com just because one of 
them doesn't want to do a bit of legwork like everybody else in that 
situation did. Some of us use com ports at 115200 or 230400 bps.

Besides - as soon as you have one other device with that access method,
it's actually less work!

Regards,
	-is