the cost of EXPORT_SYMBOL_GPL

[Tomek The Messenger]

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 at kaiser.cx> wrote:

> Hello Greg and all,
>
> Thus wrote Greg KH (greg at kroah.com):
>
> > 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 at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20200617/01b0a694/attachment-0001.html>