Drivers and objects seem interchangeable to me except that drivers get registered and checked against devices that are found during enumeration, that weren't mentioned in devicetree.cb. Either one seems to get linked into the correct place if the device is mentioned in the device tree.
Are there other differences? Should I2C devices use objects, since you can't scan for them?
Thanks, Myles
Myles Watson wrote:
Should I2C devices use objects, since you can't scan for them?
Makes sense. Either way I strongly favor having a policy for this, so that the tree is consistent.
Making it a driver seems easier to enforce/explain since it provides an *_ops struct.
On the other hand a phony ops struct is bad in so many ways. Less is more, no?
//Peter
On Wed, Sep 23, 2009 at 12:42 PM, Peter Stuge peter@stuge.se wrote:
Myles Watson wrote:
Should I2C devices use objects, since you can't scan for them?
Making it a driver seems easier to enforce/explain since it provides an *_ops struct.
On the other hand a phony ops struct is bad in so many ways. Less is more, no?
My impression was that the ops struct works fine, but you can't scan for it because I2C is missing the equivalent of PCI vendor/device IDs. In what way is the ops struct phony?
Thanks, Myles
Myles Watson wrote:
In what way is the ops struct phony?
The device can not be discovered so code must know that the device is there, and if code does, the ops provide no benefit but add confusion and undesirable indirection.
//Peter
On Wed, Sep 23, 2009 at 2:48 PM, Peter Stuge peter@stuge.se wrote:
Myles Watson wrote:
In what way is the ops struct phony?
The device can not be discovered so code must know that the device is there, and if code does, the ops provide no benefit but add confusion and undesirable indirection.
I'd be interested to see the alternative code. Devices that can't be probed for can still have resources that need to be read and set and init functions to call.
Myles
Myles Watson wrote:
I'd be interested to see the alternative code.
Fair enough. I have none, but if it works as an object without ops then is any more code needed?
Devices that can't be probed for can still have resources that need to be read and set and init functions to call.
Yes, but wouldn't that all need to be done by code with knowledge of the device (ie. just use static functions in the file) anyway?
//Peter
Myles Watson wrote:
I'd be interested to see the alternative code.
Fair enough. I have none,
It wasn't supposed to be a challenge. Just that I could tell we weren't understanding each other somehow. Pseudo code would have been fine.
but if it works as an object without ops then is any more code needed?
Ah. There's the point I've been missing in your argument. It works _with_ ops in the object. The ops get linked in to the device tree, so they get used by the correct device even though it can't be discovered.
Devices that can't be probed for can still have resources that need to be read and set and init functions to call.
Yes, but wouldn't that all need to be done by code with knowledge of the device (ie. just use static functions in the file) anyway?
Yes. The problem is how to call them if you don't have an ops structure somewhere.
Thanks, Myles
Peter Stuge wrote:
Myles Watson wrote:
In what way is the ops struct phony?
The device can not be discovered so code must know that the device is there, and if code does, the ops provide no benefit but add confusion and undesirable indirection.
Not really.. It does not make much sense to go away from an object oriented interface used for all other devices just because the one device can not be autodetected...
Stefan
Stefan Reinauer wrote:
Peter Stuge wrote:
Myles Watson wrote:
In what way is the ops struct phony?
The device can not be discovered so code must know that the device is there, and if code does, the ops provide no benefit but add confusion and undesirable indirection.
Not really.. It does not make much sense to go away from an object oriented interface used for all other devices just because the one device can not be autodetected...
I think the deal is this:
drivers are not referenced. This means if they're part of an .a archive they're dropped while linking.
That hurts for drivers, because they'd never end up in the image.
However, for objects we enjoy this optimization. If a .o file has no used symbols, it will not end up in the binary. Saves us a few bytes at every corner.
Stefan
Myles Watson wrote:
Drivers and objects seem interchangeable to me except that drivers get registered and checked against devices that are found during enumeration, that weren't mentioned in devicetree.cb. Either one seems to get linked into the correct place if the device is mentioned in the device tree.
Are there other differences? Should I2C devices use objects, since you can't scan for them?
Some structures defined in the code are put in an extra section in the binary for enumeration. Those are:
#define __console __attribute__((used, __section__ (".rodata.console_drivers"))) #define __cpu_driver __attribute__ ((used,__section__(".rodata.cpu_driver"))) #define __pci_driver __attribute__ ((used,__section__(".rodata.pci_driver")))
All others don't need to be "drivers"
Stefan
-
Myles Watson -
Peter Stuge -
Stefan Reinauer