On Tue, Sep 18, 2018 at 18:52:34 +0900, Rin Okuyama wrote: > On 2018/09/18 18:21, Valery Ushakov wrote: > > On Tue, Sep 18, 2018 at 12:17:41 +0900, Rin Okuyama wrote: > > > > > > @@ -278,8 +279,10 @@ hpckbd_keymap_setup(struct hpckbd_core * > > > > * XXX The way this is done is really wrong. The __UNCONST() > > > > * is a hint as to what is wrong. This actually ends up > > > > modifying > > > > * initialized data which is marked "const". > > > > + * > > > > * The reason we get away with it here is that on sh3 kernel > > > > - * is directly mapped. > > > > + * is directly mapped. For mips, read-only data is mapped > > > > + * read/write at the moment. > > > > */ > > > > Is this distinction necessary? My guess would be that on mips the > > reason it works is exactly the same: the kernel is directly mapped > > i.e. we bypass MMU for these accesses. > > > > If that's indeed the case, the "at the moment" part of the comment > > would be misleading, as there's no other moment in the future where it > > becomes false. > > > > Please, can you clarify? > > Sorry for ambiguous expression. I'm not a mips guy and I should > confirm this before commit. This function is called before > pmap_bootstrap(). Does this mean that your argument is true? > If so, I will update the comment.
I think sh3 (the hardware) mostly copied mips memory organization, so I *guess* our kernel works more or less the same on both in this regard. So I pmap_bootstrap will later set up the MMU for things like malloc, but - I *guess* - the kernel itself still remains directly mapped (va == pa, no MMU translation or permission checks). But I know nothing about mips :) -uwe
