Hi James, > Hi gengdongjiu, > > On 26/02/18 16:13, gengdongjiu wrote: > > 2018-02-24 1:58 GMT+08:00 James Morse <james.mo...@arm.com>: > >> On 22/02/18 18:02, Dongjiu Geng wrote: > >>> The RAS SError Syndrome can be Implementation-Defined, > >>> arm64_is_ras_serror() is used to judge whether it is RAS SError, but > >>> arm64_is_ras_serror() does not include this judgement. In order to > >>> avoid function name confusion, we rename the arm64_is_ras_serror() > >>> to arm64_is_categorized_ras_serror(), this function is used to judge > >>> whether it is categorized RAS Serror. > >> > >> I don't see how 'categorized' is relevant. The most significant ISS > >> bit is used to determine if this is an IMP-DEF ESR, or one that uses the > >> architected layout. > > > > From the name arm64_is_ras_serror(), it used to judge whether this is > > RAS Serror, but arm64_is_ras_serror() think the IMP-DEF SError is not > > RAS SError, as shown the code note and code in[1]. > > > In fact the IMP-DEF SError is also RAS SError, so when I read the > > code, it looks like > > This is just you then. No-one else has your imp-def:RAS error ESR values. > > This would be like me adding some impdef branch instruction, then claiming > aarch64_insn_is_branch() doesn't take account of my private additions. > > I agree the name is assuming all architected ESR are RAS-errors, and that > impdef ESR are just that: impdef, that's all we know about them. > Unless this causes us to do the wrong thing, I don't think it matters. > Obviously we would need to change it if a new architected ESR is added.
Ok, let us keep the current code and not change it until a new architected ESR is added
