)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1002047,"name":"Evgeniy Naydanov","email":"eugnay@gmail.com","username":"en-sc"},"change_message_id":"cfd916985abc75ca879853c6e61cddbf6107fa36","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"759b4167_ded76d21","updated":"2026-02-16 12:47:33.000000000","message":"TBH, I believe this extra validation is unnecessary.\nThe issue is -- we don\u0027t know for certain the cause. It may be a JTAG communication issue. It also may be some other HW bug. IMHO if OpenOCD is working with a buggy HW it should be \"optimistic\", avoiding erroring out of an operation unless necessary -- this just gives more options when investigating the rootcause.\n\nTo me it\u0027s somewhat similar to the following: imagine a read of `x0/zero` GPR that returns a non-zero value. Should the OpenOCD also error-out on such operation? IMHO, it should not. There can be a warning in place that notifies the user that there is an issue with the HW, but if OpenOCD does not need to rely on the fact that `x0/zero` is always zero it can continue working just fine.\nSee [1] for a similar discussion (AFAIK Jan\u0027s point of view is different).\n\nIMHO the same logic applies here.\n\nIn any case, I don\u0027t feel too strongly about this.\n\n1: https://github.com/riscv-collab/riscv-openocd/pull/1233","commit_id":"7620054f324496e7f22ff33a4ea1a78997a93293"}]}