bus_.*_resource() and rid

[John Baldwin]

On Monday, September 28, 2015 03:01:13 PM Pokala, Ravi wrote:
> -----Original Message-----
> From: John Baldwin <jhb at freebsd.org>
> Date: 2015-09-23, Wednesday at 08:07
> To: Ravi Pokala <rpokala at panasas.com>
> Cc: "freebsd-hackers at freebsd.org" <freebsd-hackers at freebsd.org>
> Subject: Re: bus_.*_resource() and rid
> 
> >Yes, you'd have to grumble around with kgdb to see rids.  We might store
> >rids in 'struct resouce *' now so we could possibly expose those to
> >devinfo.
> 
> Survey says "no":
> 
> sys/sys/rman.h:
>  89 /*
>  90  * The public (kernel) view of struct resource
>  91  *
>  92  * NB: Changing the offset/size/type of existing fields in struct
> resource
>  93  * NB: breaks the device driver ABI and is strongly FORBIDDEN.
>  94  * NB: Appending new fields is probably just misguided.
>  95  */
>  96 
>  97 struct resource {
>  98         struct resource_i       *__r_i;
>  99         bus_space_tag_t         r_bustag; /* bus_space tag */
> 100         bus_space_handle_t      r_bushandle;    /* bus_space handle */
> 101 };
> 
> 
> We *do* keep the rid in (struct resource_i):

Ah, I did mean to include 'struct resource_i' as part of 'struct resource'.
They are really stored as the same structure, and you can use rman_get_rid()
on a struct resource.

> I have a one-line change to dump_rman() to include the RID along w/ the
> start and end address. That at least got me what I was interested in from
> ddb.

Neat, can you share that?

> As for `devinfo', it looks like (struct u_resource) and (struct u_rman)
> don't include the RID either:

Fooey.  That would be a bit of a PITA to fix then.

> I ultimately just added a "next_rid" field to the softc, saving the value
> after a successful call to bus_set_resource() and then incrementing it.
> That way, each subsequent resource I add for an instance of the device
> gets a unique value, which appears to be the only constraint for IOPORT
> resources. In any case, with that change, both the original and the new
> resource are able to be set and allocated.

So there's actually a 'resource_list_add_next()' that bus drivers can use that
does this, but that doesn't help you in this case. :(  Yes, in general I/O
resources need to have unique RIDs (though I can think of one case that
violates that: the resources for I/O windows in a PCI-PCI bridge that has
ISA decoding enabled all share the same rid).

-- 
John Baldwin