On 22.03.2006, at 22:23, John-Mark Gurney wrote:
Okay, now I have got the bus device, the child device. My current
trouble is
that I want bus driver to provide some methods to child drivers.
So I created saa_bus_if.m file, declared some methods there, made
implementation
in bus driver and added them using
DEVICE_METHOD(saa_bus_some_method, saa_some_method_impl),
and added the saa_bus_if.c to child driver SRCS.
You should only add the saa_bus_if.h to the child driver.. the if.c
file is for the part that implementes the bus.. be it one driver, or
part of the kernel... I'm surprised you aren't getting duplicate
symbols...
Now, when I do SAA_BUS_SOME_METHOD(card, ...) inside bus driver, it
works just as
expected. But when I do SAA_BUS_SOME_METHOD(device_get_parent
(subdev), ...)
inside subdriver, it happens that KOBJLOOKUP(...) returns pointer to
generic
function (which returns ENXIO) rather than pointer to my
implementation.
The questions are:
Am I going the Right Way(tm) when exporting functions to child
drivers like that?
If yes, what I must do in order to get the real implementation, not
the default one?
If no, what is The Right Way(tm)?
Most of the drivers have code in the default, that will reapply the
function to the parent, so you don't have to do the device_get_parent
in your driver.. They also implement their own lower case wrappers
too...
That's just for sure... I want the method I call to work with the bus'
softc, not with the child's one. Right now I am not sure whether I
really want to have different softc's for the bridge driver and for
tuner.
This very well could be due to the fact that you're including your
interface twice, and that the second time isn't seeing the same cache
entry in the KOBJ cache..
Why are you compiling the _if.c twice? If this was to get around
undefined symbols at module load time, I found that you need to add a
MODULE_DEPEND to the module the provides the symbol...
Yeah, I found that out myself already... I really was missing
MODULE_VERSION in a bus driver and MODULE_DEPEND in a child driver.
For now, I have all pieces of a puzzle laid out. I'm able to identify
Philips IC (bridge), check it's subdevice, and subdriver is able to ask
it's parent to do some I2C conversation to test presence of tuner.
I know how bus driver can do something with a child device, and vice
versa.
I think that it's time to try to write an article, as Milan Obuch
suggested.
I hope it will save someone from bumping into the walls just like I did.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
