Date: Mon, 28 Sep 2015 11:09:29 -0700 From: John Baldwin <jhb@freebsd.org> To: "Pokala, Ravi" <rpokala@panasas.com> Cc: Francois Tigeot <ftigeot@wolfpond.org>, "cem@FreeBSD.org" <cem@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: bus_.*_resource() and rid Message-ID: <3440562.CxbPY93XVj@ralph.baldwin.cx> In-Reply-To: <D22E9D9D.146A5C%rpokala@panasas.com> References: <D214E963.145154%rpokala@panasas.com> <1637146.Rv3dkk0gMi@ralph.baldwin.cx> <D22E9D9D.146A5C%rpokala@panasas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, September 28, 2015 03:01:13 PM Pokala, Ravi wrote:
> -----Original Message-----
> From: John Baldwin <jhb@freebsd.org>
> Date: 2015-09-23, Wednesday at 08:07
> To: Ravi Pokala <rpokala@panasas.com>
> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3440562.CxbPY93XVj>