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