<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2020 at 2:36 PM Martin Kaiser <<a href="mailto:lists@kaiser.cx">lists@kaiser.cx</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">Hello Greg and all,<br>
<br>
Thus wrote Greg KH (<a href="mailto:greg@kroah.com" target="_blank">greg@kroah.com</a>):<br>
<br>
> Please do not do that. There are valid kernel apis to grant access to<br>
> registers easily,<br>
<br>
the most simple case would be a "reset reason" register within the<br>
chip's address space. A hand-crafted driver would ioremap the region and<br>
implement a sysfs show method that reads the register.<br>
<br>
What do you recommend for providing read access to such a register<br>
via sysfs? Is this a job for the userspace I/O (UIO) subsystem?<br>
<br>
Thanks,<br>
Martin<br>
<br>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
<a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</blockquote></div>