[PATCH] powerpc/mm: Allow user space to map rtas_rmo_buf

[Denis Kirjanov]

On 1/22/16, Michael Ellerman <mpe at 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 at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev