the cost of EXPORT_SYMBOL_GPL

[Tomek The Messenger]

> If we have one unique sysfs interface then it is easier for
> everyone: tester, developer to proceed with such device, testing or
> debugging.

>>No - not really.  Because if you're mapping 3 or 4 SOC resets reasons to
>>one thing, you then have to write code that says "If it's SoC 1, then
>>a bit 12 being set was a memory error, but if it's SOC 2 bit 12 means a
>>PCI bus reset and a memory parity error is bit 17, but a memory ECC
>>error is bit 4."

>>And if the meaning of the reset register is different, a lot of *other*
things
>>are probably different too, which is an argument for just having separate
>>drivers for each SoC.

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:
/sys/resetreg - 3 separate drivers plus  one core driver where there  is
common  part
/sys/otherfunctionality- as Above
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.
...
/sys/functionalityN  -> separate driver for intel, TI, Xilinx

On Wed, Jun 17, 2020 at 3:34 PM Ahmad Fatoum <a.fatoum at pengutronix.de>
wrote:

> 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 |
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20200617/966bfb3d/attachment-0001.html>