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.

So maybe in other words.

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.

Apart from reset_reason You have many other functionalities like kernel boot source (tftp, spi).

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

cat /sys/resetreg/reason

as output they got in string format for example COLD_REBOOT.

They read:

/sys/bootreg/source

As output they got in string format TFTP.

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.

And there is separate kernel module which implements read/write access to each of directory in /sys. So we use here linux API:

kobj = kobject_create_and_add("bootreg", NULL);

sysfs_create_groups(kobj, ...)

So hope that You have now good understanding.

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.

On Wed, Jun 17, 2020 at 10:55 AM Greg KH <greg@kroah.com> wrote:

On Wed, Jun 17, 2020 at 09:58:03AM +0200, Tomek The Messenger wrote:
> Hi
> Thanks for reply.
> We make some proxy layer in linux /sys. So for example we have directories:
> /sys/resets
> /sys/routers

Really? That's a total abuse of sysfs, don't do that.

Seriously, that's not ok at all.

> etc.
> So if user wants to get to know what is the reset reason he doesn't use
> devmem 0xfff...., he just read the file in /sys/resets/..
> If user wants to know some routing path he doesn't read registers via
> devmem, he only reads some file in /sys/routers which gives him output.
> So this is in order to facilitate reading/writing to registers. Instead of
> searching in documentation concrete registers users have some helper proxy
> layer in sysfs. And for each directory in /sys there is separate kernel
> module. Division is based on some functionalities like resets, routing etc.
> And the problem is should this 6th kernel module perform role of getting
> access to all registers or only to parts which are used by more than one
> kernel module? Now I am using second approach but when I am looking at the
> code it looks terrible. For example #define for register X and function to
> access it, is in module A, for egister Y in module B, for register Z in 6th
> kernel module. There is mess I think and maybe better approach is to put
> all API to 6th kernel module?

I really do not understand at all, sorry. Why are you using sysfs for
something that it is not designed for? And sysfs directory structure
has nothing to do with kernel module names/structures.

Do you have a pointer to your code somewhere so that we can review it
and suggest the correct apis you should be using instead?

thanks,

greg k-h