<div dir="ltr"><div>Maybe some pseudo-code:</div>So in other to implement file /sys/resetreg/reason You have to write:<div><br></div><div>static ssize_t reason_show(struct kobject *kobj,<br> struct kobj_attribute *attr, char *buf)<br>{<br> u32 val;<br><br>val = some_readAPI_to_get_reboot_reason();<br><br>
return scnprintf(buf, PAGE_SIZE, "%d\n", (u32)(val));
<br> }<br><br>static struct kobj_attribute reason = __ATTR_RW(reason);<br><br>static struct attribute *reason_attrs[] = {<br> &reason_attribute.attr,<br><br> NULL,<br>};<br>ATTRIBUTE_GROUPS(some_group);<br></div><div><br></div><div>Then this some_group symbol goes as second parameter to sysfs_create_groups.</div><div>So functions *_show go to separate kernel modules. But function
some_readAPI_to_get_reboot_reason() I think should be placed in 6th kernel module, so in kernel module with read/write specific operations to given soc.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2020 at 11:17 AM Tomek The Messenger <<a href="mailto:tomekthemessenger@gmail.com">tomekthemessenger@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">OK, so I had to wrongly described something because in my company this is popular approach to use /sys as some abstract layer to get access to registers.<div>So maybe in other words.</div><div>Let's say You have many socs. In one soc reset_reason can be gotten from devmem 0xfff.... In other soc reset_reason can be gotten through i2c read from some device.</div><div>Apart from reset_reason You have many other functionalities like kernel boot source (tftp, spi).</div><div>And let's assume you are tester. It is hard for those people to remember addresses, remembering and checking all the time how to read reset_reason or routing, then extract value from proper bits. Instead of raw addresses they have interface in /sys in the form of files. For example they read</div><div>cat /sys/resetreg/reason</div><div>as output they got in string format for example COLD_REBOOT.</div><div>They read:</div><div>/sys/bootreg/source</div><div>As output they got in string format TFTP.</div><div>And that is on each soc. This is good that registers, the way of access is hidden under interface. It is easier and faster to debug anything with such approach even for developers not only testers.</div><div>And there is separate kernel module which implements read/write access to each of directory in /sys. So we use here linux API:</div><div>kobj = kobject_create_and_add("bootreg", NULL);<br></div><div>sysfs_create_groups(kobj, ...)</div><div>So hope that You have now good understanding.</div><div>I cannot show the code as I don't if I am allowed. I am about half an year in kernel development team, so sometimes I have some doubts. And now my doubts are where to put API for read/write operations as I mentioned above.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2020 at 10:55 AM Greg KH <<a href="mailto:greg@kroah.com" target="_blank">greg@kroah.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jun 17, 2020 at 09:58:03AM +0200, Tomek The Messenger wrote:<br>
> Hi<br>
> Thanks for reply.<br>
> We make some proxy layer in linux /sys. So for example we have directories:<br>
> /sys/resets<br>
> /sys/routers<br>
<br>
Really? That's a total abuse of sysfs, don't do that.<br>
<br>
Seriously, that's not ok at all.<br>
<br>
> etc.<br>
> So if user wants to get to know what is the reset reason he doesn't use<br>
> devmem 0xfff...., he just read the file in /sys/resets/..<br>
> If user wants to know some routing path he doesn't read registers via<br>
> devmem, he only reads some file in /sys/routers which gives him output.<br>
> So this is in order to facilitate reading/writing to registers. Instead of<br>
> searching in documentation concrete registers users have some helper proxy<br>
> layer in sysfs. And for each directory in /sys there is separate kernel<br>
> module. Division is based on some functionalities like resets, routing etc.<br>
> And the problem is should this 6th kernel module perform role of getting<br>
> access to all registers or only to parts which are used by more than one<br>
> kernel module? Now I am using second approach but when I am looking at the<br>
> code it looks terrible. For example #define for register X and function to<br>
> access it, is in module A, for egister Y in module B, for register Z in 6th<br>
> kernel module. There is mess I think and maybe better approach is to put<br>
> all API to 6th kernel module?<br>
<br>
I really do not understand at all, sorry. Why are you using sysfs for<br>
something that it is not designed for? And sysfs directory structure<br>
has nothing to do with kernel module names/structures.<br>
<br>
Do you have a pointer to your code somewhere so that we can review it<br>
and suggest the correct apis you should be using instead?<br>
<br>
thanks,<br>
<br>
greg k-h<br>
</blockquote></div>
</blockquote></div>