On Thu, Aug 11, 2011 at 8:18 PM, Linus Walleij <[email protected]> wrote:
> 2011/8/11 Jassi Brar <[email protected]>:
>
>> Do you have any reason for using device pointer and strings, other
>> than just "because clock and regulator use them" ??
>
> Basically no.

Dear, I am speechless !!
Best of luck.

>>>> 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 think I know why and how clkdev and regulator use strings.
Here we are talking about dmac possibly expressing 8 parameters
as strings, not just 2.


>> 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.
Let me provide you even more 'ammunition'
ASoC and USB-Gadget employs strings too
Though only Regulators, ASoC and CLKDEV(?) really _have-to_
employ strings.
USB-Gadget use them mainly for historical reasons - we can very well
replace that scheme with bit-fields as I propose.

------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

Reply via email to