the cost of EXPORT_SYMBOL_GPL

[Ahmad Fatoum]

Hello,

On 6/17/20 2:48 PM, Tomek The Messenger wrote:
> 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.

It also gets more interesting when you have multiple reset reasons in the
same system, e.g. SoC power control differentiates between POR, external and
Watchdog reset and Watchdog OTOH differentiates between watchdog reset and
regular reset and then you might have an external PMIC with an integrated
watchdog that overrides both.

In projects I've been involved in, the bootloader did the boot reason computation[1]
and was the one to act on it, so communication to the kernel wasn't of high
importance. It would be great to have:

1) an upstream device tree binding for reset reason communication from bootloader
   to Linux
2) a mainline User API to query the reset reason
3) a mainline in-kernel API for drivers to set reset reasons

Watchdog drivers already have a WDIOF_CARDRESET flag that could be folded into
this. If you feel up to the task and go along with upstreaming it, you'll
save yourself (and future colleagues who need to debug locking problems between
your module and mainline kernel drivers) a lot of hassle.

[1]: https://barebox.org/doc/latest/user/reset-reason.html

Cheers
Ahmad


> 
> 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
>>
> 
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |