On Tue, Jul 09, 2024 at 01:27:25AM -0500, Naik, Avadhut wrote: > IIUC, its an abbreviation of a Latin word and is used as a synonym for "namely" > or "that is to say". > Might not be the best choice in this case. Will change it. I learn new stuff every day: https://en.wikipedia.org/wiki/Viz. > Userspace error decoding tools like the rasdaemon gather related hardware error > information through the tracepoints. As such, its important to have these two > registers in the tracepoint so that the tools like rasdaemon can parse them > and output the supplemental error information like FRU Text contained in them. Put *that* in the commit message - do not explain what the patch does. > Got it. The first SoB entry is of the primary author. The successive SoB's are > from the people handling and transporting the patch. Exactly! > IOW, the route taken by a patch, as its propagated, to maintainers and eventually > to Linus, should be evident from the SoB chain. You got it. > With this set, the first two elements of the vendor data dynamic array are SYND 1/2 > registers while the third element is MCA_CONFIG (added through patch 4 of the set). > Now, in rasdaemon, SYND1/2 register contents (i.e. first two fields) are interpreted > as FRU Text only if BIT(9) of MCA_CONFIG (third field) is set. > > Thus, we depend on array's layout for accurate FRU Text decoding in the rasdaemon. So it sounds to me like we want to document and thus freeze the vendor-specific blob layout because tools are going to be using and parsing it. And this will spare us the kernel version checks. And new additions to that AMD-specific blob will come at the end and will have to be documented too. That sounds like an ok compromise to me... Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
