This is the case about which Martin write shortly. Then let's assume on another soc reset reason is not stored in chip's address space memory mapped to address 0xfff.... but it is accessed via some spi operation. On another soc reset reason is still memory mapped but to different address 0xfff... And then let's assume there are 30-40 such functionalities like reset_reason. If we have one unique sysfs interface then it is easier for everyone: tester, developer to proceed with such device, testing or debugging. You don't waste time to read documentation each time, checking what address is/how to read each functionality. You have this hidden in kernel modules code and can access via cat/echo to /sys.
On Wed, Jun 17, 2020 at 2:36 PM Martin Kaiser <lists@xxxxxxxxx> wrote:
Hello Greg and all,
Thus wrote Greg KH (greg@xxxxxxxxx):
> Please do not do that. There are valid kernel apis to grant access to
> registers easily,
the most simple case would be a "reset reason" register within the
chip's address space. A hand-crafted driver would ioremap the region and
implement a sysfs show method that reads the register.
What do you recommend for providing read access to such a register
via sysfs? Is this a job for the userspace I/O (UIO) subsystem?
Thanks,
Martin
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
