On Wed, Jun 17, 2020 at 04:26:49PM +0200, Tomek The Messenger wrote:
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
Again, use the specific subsystem for these values, don't try to expose your own mess in sysfs, especially with "raw" kobjects. You will run into loads of problems that way. greg k-h