On 1/22/16, Michael Ellerman <m...@ellerman.id.au> wrote: > On Fri, 2016-01-22 at 11:58 +0530, Vasant Hegde wrote: >> On 01/22/2016 10:59 AM, Michael Ellerman wrote: >> > On Thu, 2016-01-21 at 21:45 +0530, Vasant Hegde wrote: >> > >> > > With commit 90a545e9 (restrict /dev/mem to idle io memory ranges) >> > > mapping >> > > rtas_rmo_buf from user space is failing. Hence we are not able to make >> > > RTAS syscall. >> > >> > Having said that, why the <expletive deleted> is librtas mapping >> > /dev/mem in >> > the first place? Unless there is a very good reason, and probably even >> > if there >> > is, we should fix that to use a sane API. >> >> We use rtas system call. We use /dev/mem interface to map the RTAS memory >> region >> (allocated by kernel and information is passed to user space via procfs) >> so that >> we can read/write to RTAS memory. >> >> I do not have historical information. May be Nathan has more information >> on this. > > Yeah, we need to dig into what it's actually doing and why. I had a quick > look > but it wasn't obvious. > > We should not need 1) a system call, 2) a proc interface, and 3) a mmap of > /dev/mem. > > If the syscall's not sufficient and we really need to mmap, we should create > a > device which can then be mmapped in a more standard way. > > Having said that, Nathan's been moving more of the hotplug logic into the > kernel, so I'm also not clear on how much of the existing API we will need > in > the future. So yep hopefully Nathan can chime in.
Yeah, but if we're going to move to only one interface to work with RTAS we can break existing applications. > > cheers > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
