On 1/22/16, Michael Ellerman [off-list ref] wrote:

On Fri, 2016-01-22 at 11:58 +0530, Vasant Hegde wrote:

quoted

On 01/22/2016 10:59 AM, Michael Ellerman wrote:

quoted

On Thu, 2016-01-21 at 21:45 +0530, Vasant Hegde wrote:

quoted

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