Hi, >> > You are right... Let me just prints the error code instead. Anyone who >> > care will have to do post processing. >> >> Don't forget about the usability of the driver. If a user has to go >> open manuals when an error happens, you could just as well report naked >> register values and have a tool decode them. >> >> And this strategy (mcelog) turned out to be a real PITA, IMO. >> >> > Future or existent next generation may re-define them. >> >> You could easily have a strings array of per-family or per-soc error >> descriptions. For an example, take a look at drivers/edac/mce_amd.c >> which decodes MCEs on all relevant AMD machines. This is much more >> user-friendly than dumping register values which most people have no >> idea of where to start looking (and they don't really need to). > > That would require having a way to identify the SoC with a distinct > compatible string. I don't know if a name exists for X-Gene that could > be used here. > I am not sure either but will try to figure this out. The issue with compatible string is the requirement to have FW go and patch it up. We don't have multiple DT's for each minor version of the chip. -Loc -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
