Reading acpi memory from a driver attached to hostb

[Andre Albsmeier]

John, apparently you sent me an email (thanks a lot) which I never
received (we have to blame our company's spam filters which I do
not control). I'll comment on it here in my reply to Doug...

On Thu, 23-Jul-2009 at 07:25:40 -0700, Doug Ambrisko wrote:
> John Baldwin writes:
> | On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote:
> | > On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote:
> | > > Andre Albsmeier writes:
> | > > | > 
stripping some elder stuff
> | > > | 
> | > > | I assume it is possible somehow, I am just too stupid (it is the first
> | > > | driver I wrote). John, for easy reference, here is my initial message:
> | > > | 
> | > > | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html
> | > > | 
> | > > | Please remember all, that I need the access to the acpi0 memory location
> | > > | only for a few reads during probing/attaching, not later.
> | > > | 
> | > > | I have also read somewhere that, when resources are allocated, the
> | > > | system "walks up" the device tree until it finds the resource. Since
> | > > | my driver is below hostb0 and hostb0 is below acpi0 I thought it
> | > > | should work but it doesn't..
> | > > 
> | > > FWIW, you might look at ipmi(4) especially in some early states since
> | > > it can probe and attach in many ways (isa, acpi, pci etc.) and had to
> | > > figure out the best way to attach.  Also it had various front ends.
> | > > If I recall correctly, I did a find for a driver (ie. acpi) then
> | > > select the first instance.  Once you get that handle then you can 
> | > > request device resources from it, get the info you need then release
> | > > that stuff.  However, you won't get the module auto-loading part
> | > > that you would get if you created a module that depended on both.
> | > > That might get you enough of a hint.  Also there are some generic
> | > > stuff to read various memory bits like SMBIOS areas etc.  This is
> | > > used in ipmi(4) as well since the attachment can be defined in SMBIOS.
> | > > If you have a specific question, about why the driver did something
> | > > I should recall that.  The ipmi(4) driver is in fairly clean.  There
> | > > is some improvements I still need to do on probe/attachment that
> | > > causes a bogus ipmi1 at times.
> | > 
> | > Thanks a lot for this interesting information. I see, things are more
> | > complicated than I thought. There is no easy way having a quick glance
> | > at "foreign" memory during probing. Now I have to figure out how to get
> | > the order of probing/attaching done. One thing I could do is:
> | > 
> | > 1. attach mydriver_ACPI to acpi0
> | > 
> | > 2. probe mydriver under hostb0, check if we need access to
> | >    sysresources from acpi0 (depends on the chipset found).
> | >    If no, goto 5.
> | > 
> | > 3. ask mydriver_ACPI about stuff I want to know (HOW?)
> | > 
> | > 4. tell mydriver to detach from acpi0 (HOW?)
> | > 
> | > 5. attach mydriver to hostb0 and do my work
> | > 
> | > What I would like more is something like:
> | > 
> | > 1. probe mydriver under hostb0, check if we need access to
> | >    sysresources from acpi0 (depends on the chipset found).
> | >    If no, goto 3.
> | > 
> | > 2. ask mydriver_ACPI to attach to acpi0, give me the info
> | >    I want, detach mydriver_ACPI (HOW?)
> | > 
> | > 3. attach mydriver to hostb0 and do my work
> | 
> | Did you try 
> | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your 
> | driver that is a child of hostb0?

I tried this, well, something similar: I had to do 4 times
device_get_parent() to end up at acpi0:

mydriver -> hostb0 -> pci0 -> pcib0 -> acpi0

> 
> That should basically work since almost everything is a child of acpi.

Thats what I hoped indeed. It would be a lot simpler than
working with two drivers which have to communicate with each other.

> However, the depth could change so running through the device_get_parent
> and then checking the name might be good.

I thought the same so I decided to lookup the acpi devclass
and then acpi0 from there.

To be sure, I compared the resulting pointers of acpi0 with
the one found after the four device_get_parent(). They were
the same.

> 
> BTW, there is an example in sys/compat/linsysfs/linsysfs.c
> in which I run the entire bus tree via linsysfs_run_bus which is
> recursive and started from linsysfs_init.
> 
> As John and I say, you don't need to "attach" to acpi just allocate
> what you need, access it, then release it.  If you need to hold on
> it then it becomes more involved.  Since you never attach then you
> don't need to dettach just release the resources you grabbed (
> ie. bus_release_resource what you bus_alloc_resource).

Well, then I still must be doing something wrong. I have attached
my driver skeleton which does the following:

1. device_identify() which does a device_add_child() if needed

2. device_probe() which just tries to bus_alloc_resource() a
   SYS_RES_MEMORY resource from acpi0. If it works (which never
   does :-(), call bus_release_resource(). device_probe() always
   returns ENXIO so the whole driver never attaches.

Especially in device_probe() I do:

1. Search for acpi0.

2. List the resources of acpi0. I compared the list to my "devinfo -r"
   output and they are the same.

3. Take the first SYS_RES_MEMORY resource from the list in 2. and
   try to bus_alloc_resource() it. This never succeds.

Maybe you find the bug in there, I run out of ideas. It's not much
of code, most of it are device_printfs for debugging...

I have also attached the Makefile in case someone wants to kldload
it on his machine. I would be very interested if it worked there.

Thanks to you and John, of course.

	-Andre
-------------- next part --------------
KMOD    = eccmon
SRCS    = eccmon.c device_if.h bus_if.h pci_if.h
NO_MAN  = 1

CFLAGS+=-DDEVEL

.include <bsd.kmod.mk>