2011/8/11 Jassi Brar <jassisinghb...@gmail.com>: > Do you have any reason for using device pointer and strings, other > than just "because clock and regulator use them" ??
Basically no. But I think these frameworks are very workable and proven to work in practice. So I like them. When setting up the platform the coder would to be aware that there are totally orthogonal concepts, which IMO makes things complicated. >>> Do you propose to implement a string parser in the core ?! >> >> Yes, the clock and regulator framework already does that. >> But it is only used when you cannot pass in a struct device * >> directly, like from device tree. > > Dude, I have utter disrespect for using strings in a case such as > expressing requirements. It's mainly a strcmp(), and it's only comparing to the well-established namespace that all devices have anyway, due to the way the device model is done. Basically when binding clocks or regulators it's: struct device *dev; strcmp(map_string, dev_name(dev)); By this time struct device exist of course, since it's the device driver calling to get its clock/regulator. dev_name() comes from <linux/device.h> and basically takes the kobject name or an optional initilizer name for the device. So the names are pretty static, you don't need to parse them, just compare. > I have already explained how we can easily and in a _better_ way > do without them (again see my last reply to Vindo's setup). > Tell me 1 reason why using strings, in this case, would be better ? I have no other reasons than the above. People like Russell (clkdevice) and Liam Girdwood (regulator) who I know are smarter than me and have worked with these subsystems for years choose that model, so I trust their judgement. Thanks, Linus Walleij ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
