"McGranaghan, Sean" <SMcGranaghan@vanteon.com> writes:

> 	#define rCTRLREG(b)	(*(b + REG_OFFSET))
> 
> 	vaddr_t b;
> 
> 	b = (vaddr_t) bus_space_vaddr(sc->sc_iot, sc->ioh);
> 	rCTRLREG(b) |= BITMSK;
> 
> Seems preferable to:
> 
> 	u_int32_t value;
> 
> 	value = bus_space_read_4(sc->sc_iot, sc->ioh, REG_OFFSET);
> 	value |= BITMSK;
>       bus_space_write_4(sc->sc_iot, sc->ioh, offset, REG_OFFSET);
> 
> Are these equivalent?

If the types and access sizes worked out, I think that those would be
equivalent. I'm not at all sure the type operation on vaddr_t will
work there, but even ignoring that, that's not an approved use of
bus_space_vaddr() - the main purpose is exposing frame buffer
memory.

Importantly, bus_space_vaddr() doesn't always work - it only works for
bus spaces that are linearly mappable, which is not true of device
register spaces on several architectures (I/O space on x86,
sparse-mapped buses on Alpha, etc...)

> Do I need to specify a barrier after my read-modify-write?

In practice, everything currently has implicit barriers, so it's not
worth worrying about now. You would need a barrier in theory if the
later reads and writes depended critically on happening after that
bitmask was set.

        - Nathan