On 01/22/2016 04:41 AM, Denis Kirjanov wrote: > 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. >
Yes, but I doubt that anything other than librtas is using this. I don't think this interface was ever documented anywhere. -Nathan >> >> 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
