<div dir="auto"><div dir="ltr"><span style="color:rgb(80,0,80)">> If we have one unique sysfs interface then it is easier for<br>> everyone: tester, developer to proceed with such device, testing or<br>> debugging.<br><br></span>>>No - not really. Because if you're mapping 3 or 4 SOC resets reasons to<br>>>one thing, you then have to write code that says "If it's SoC 1, then<br>>>a bit 12 being set was a memory error, but if it's SOC 2 bit 12 means a<br>>>PCI bus reset and a memory parity error is bit 17, but a memory ECC<br>>>error is bit 4."<br><br>>>And if the meaning of the reset register is different, a lot of *other* things<br>>>are probably different too, which is an argument for just having separate<br>>>drivers for each SoC. <br><div><br></div><div>Yes separate drivers but the actions do by them is to create the same files in sysfs. So if somebody use intel, texas instrument or xilinx soc then in order to read reset reason or other stuff he will use sysfs. So this will look likes:</div><div dir="auto">/sys/resetreg - 3 separate drivers plus one core driver where there is common part</div><div dir="auto">/sys/otherfunctionality- as Above</div><div dir="auto">Apart from above 3 drivers where there is api to access registers from ti, Intel, xilinx. This was original question if place here all api reads/writes or only common between sysfs kernel modules.</div><div>...</div><div>/sys/functionalityN
->
separate
driver for intel, TI, Xilinx
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2020 at 3:34 PM Ahmad Fatoum <<a href="mailto:a.fatoum@pengutronix.de" target="_blank" rel="noreferrer">a.fatoum@pengutronix.de</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,<br>
<br>
On 6/17/20 2:48 PM, Tomek The Messenger wrote:<br>
> This is the case about which Martin write shortly. Then let's assume on<br>
> another soc reset reason is not stored in chip's address space memory<br>
> mapped to address 0xfff.... but it is accessed via some spi operation. On<br>
> another soc reset reason is still memory mapped but to different address<br>
> 0xfff... And then let's assume there are 30-40 such functionalities like<br>
> reset_reason. If we have one unique sysfs interface then it is easier for<br>
> everyone: tester, developer to proceed with such device, testing or<br>
> debugging. You don't waste time to read documentation each time, checking<br>
> what address is/how to read each functionality. You have this hidden in<br>
> kernel modules code and can access via cat/echo to /sys.<br>
<br>
It also gets more interesting when you have multiple reset reasons in the<br>
same system, e.g. SoC power control differentiates between POR, external and<br>
Watchdog reset and Watchdog OTOH differentiates between watchdog reset and<br>
regular reset and then you might have an external PMIC with an integrated<br>
watchdog that overrides both.<br>
<br>
In projects I've been involved in, the bootloader did the boot reason computation[1]<br>
and was the one to act on it, so communication to the kernel wasn't of high<br>
importance. It would be great to have:<br>
<br>
1) an upstream device tree binding for reset reason communication from bootloader<br>
to Linux<br>
2) a mainline User API to query the reset reason<br>
3) a mainline in-kernel API for drivers to set reset reasons<br>
<br>
Watchdog drivers already have a WDIOF_CARDRESET flag that could be folded into<br>
this. If you feel up to the task and go along with upstreaming it, you'll<br>
save yourself (and future colleagues who need to debug locking problems between<br>
your module and mainline kernel drivers) a lot of hassle.<br>
<br>
[1]: <a href="https://barebox.org/doc/latest/user/reset-reason.html" rel="noreferrer noreferrer" target="_blank">https://barebox.org/doc/latest/user/reset-reason.html</a><br>
<br>
Cheers<br>
Ahmad<br>
<br>
<br>
> <br>
> On Wed, Jun 17, 2020 at 2:36 PM Martin Kaiser <<a href="mailto:lists@kaiser.cx" target="_blank" rel="noreferrer">lists@kaiser.cx</a>> wrote:<br>
> <br>
>> Hello Greg and all,<br>
>><br>
>> Thus wrote Greg KH (<a href="mailto:greg@kroah.com" target="_blank" rel="noreferrer">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" rel="noreferrer">Kernelnewbies@kernelnewbies.org</a><br>
>> <a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
>><br>
> <br>
> <br>
> _______________________________________________<br>
> Kernelnewbies mailing list<br>
> <a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank" rel="noreferrer">Kernelnewbies@kernelnewbies.org</a><br>
> <a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
> <br>
<br>
-- <br>
Pengutronix e.K. | |<br>
Steuerwalder Str. 21 | <a href="http://www.pengutronix.de/" rel="noreferrer noreferrer" target="_blank">http://www.pengutronix.de/</a> |<br>
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |<br>
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |<br>
</blockquote></div></div>