[RFC PATCHv2 1/2] Export SoC info through sysfs
Maxime Coquelin
maxime.coquelin-nonst at stericsson.com
Fri Mar 11 10:40:05 EST 2011
>> +
>> +int __init register_sysfs_soc_info(struct sysfs_soc_info *info, int nb_info)
>> +{
>> + int i, ret;
>> +
>> + for (i = 0; i< nb_info; i++) {
>> + ret = sysfs_create_file(soc_object,&info[i].attr.attr);
>> + if (ret) {
>> + for (i -= 1; i>= 0; i--)
>> + sysfs_remove_file(soc_object,&info[i].attr.attr);
>> + break;
>> + }
>> + }
>> +
>> + return ret;
>> +}
> From functional perspective, this looks like a sysfs_create_group.
> Now it makes me wonder if this thing would make sense. Maybe it's
> better to create a node under platform and then add attributes to it, as suggested
> in V1 thread. I don't know, this could still be done by the socinfo code.
> I mean, location is still an issue it seams :-)
>
> Another thing, what could be done is, instead of creating new data structures to hold
> the attributes, a struct attribute_group could be pass instead during registration time.
> What do you think??
It would be cleaner indeed.
>> +
>> +static struct attribute *soc_attrs[] = {
>> + NULL,
>> +};
>> +
>> +static struct attribute_group soc_attr_group = {
>> + .attrs = soc_attrs,
>> +};
>
> What is the point of the above two ?
sysfs_create_group() requires attributes.
>> +
>> +int __init register_sysfs_soc(struct sysfs_soc_info *info, size_t num)
>> +{
>> + int ret;
>> +
>> + soc_object = kobject_create_and_add("socinfo", NULL);
>> + if (!soc_object) {
>> + ret = -ENOMEM;
>> + goto exit;
>> + }
>> +
>> + ret = sysfs_create_group(soc_object,&soc_attr_group);
>> + if (ret)
>> + goto kset_exit;
> You add an empty group here.
>
>> +
>> + ret = register_sysfs_soc_info(info, num);
>> + if (ret)
>> + goto group_exit;
> But the real thing happens here.
>
More information about the linux-arm-kernel
mailing list