On Wed, 17 Jun 2020 14:48:36 +0200, Tomek The Messenger said: > 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.
Or you could hire hardware engineers who don't create designs that look like they were done by crack-addicted howler monkeys, but instead did sane designs that were easier to program. You know, like being consistent with whether the registers are SPI or not, and so on. > 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.
pgpEOs4ZlMiDa.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
