On Tue, 10 May 2016, Ralf Baechle wrote: > > (we ought to handle this one day actually, for correct unaligned access > > emulation -- right now you get a repeated AdEL exception in emulation code > > for what originally was an unaligned out of range kernel XKPHYS access, > > making it a big pain to debug; I've had a hack for this since 2.4 days, > > but it should be done properly). > > Yeah, it's simply an implementation guided by the SISO principle. Shit in, > shit out. The issue you're having rarely hurts and if a simple hack can > solve it I'm in principle open to consider it for merging. The problem with my hack is it is only correct for the R4000/R4400 as I just hardwired the bits I needed to debug the issues I had. Well, maybe for a couple of other processors as well, but I'd say it's not upstream quality. > > In the old days pretty much nothing was recorded in the single Config > > register (very old chips didn't even have that -- you had to size caches > > manually for example), but stuff could often be determined via other > > means, sometimes (like probably here) without detailed checks on PRId. > > Sizing the R4000/R4400 second level cache for example. I'd call that > taking the RISC design principle to the edge :-) Or the corresponding R2000/R3000 stuff. I'm still rather sceptical about our results of cache line size probing, they seem too different from what relevant documentation says. To say nothing of the fill vs invalidation line size difference (I think we just report the latter while we're more interested in and the algorithm is supposed to report the former). Maciej
