This is a nop as eventually these flags are passed to rman_reserve_resource
which unconditionally sets RF_ALLOCATED in the new flags for a region.
However, it's really a layering violation to use RF_ALLOCATED in relation
to struct resource objects outside of subr_rman.c as subr_rman.c uses
this flag to manage it's internal tracking of allocated vs free regions.
In addition, don't document this as a valid flag in the manual. I
think the intention here was that if a caller didn't want to pass
RF_ACTIVE or RF_SHAREABLE, they could pass RF_ALLOCATED instead of 0,
but given the layering violation, I think it's best to just pass 0
instead in that case.
NB: The bhnd bus uses RF_ALLOCATED (along with RF_ACTIVE) in a
separate API to manage resource regions that are not struct resource
objects (but a separate wrapper object). It would perhaps be cleaner
if the chipc_retain_region and chipc_release_region functions used
their own flag constants instead of reusing the rman(9) flags.