All of lore.kernel.org
 help / color / mirror / Atom feed
* Customizing UIO mmap'ing
@ 2015-12-17 21:35 Kenneth Adam Miller
  2015-12-18 12:05 ` Henry Gomersall
  0 siblings, 1 reply; 5+ messages in thread
From: Kenneth Adam Miller @ 2015-12-17 21:35 UTC (permalink / raw)
  To: kernelnewbies

So, previously I think I misunderstood how to use uio_dmem_genirq. Let me
explain the way I think it currently works (bare with me, I departed from
looking at this driver after only about a week of looking at it):

Generally uio_dmem_genirq.c builds on top of uio.c, which provides a common
module basis for isolating code common to the other specific modules. But
for a specific purpose, uio_dmem_genirq.c has be either customized or
extended in order that specific memory regions can be set as accessible.
Most easily, this is done in a first come first serve approach by filling
out the details (which exactly?) left missing in uio_dmem_genirq.c, and to
start, that would be in uio_of_genirq_match
<https://proxy-us.hide.me/go.php?u=zWvu%2Fc4k0RUgdQesK%2F26T4EuwcXktyOuOa%2F3x1F0nLo5r0d9WlQEzfN928BYniutwGWnnJXkaBWcsA6D&b=29>
.

Am I correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151217/5efcb774/attachment.html 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Customizing UIO mmap'ing
  2015-12-17 21:35 Customizing UIO mmap'ing Kenneth Adam Miller
@ 2015-12-18 12:05 ` Henry Gomersall
  2015-12-18 14:15   ` Kenneth Adam Miller
  0 siblings, 1 reply; 5+ messages in thread
From: Henry Gomersall @ 2015-12-18 12:05 UTC (permalink / raw)
  To: kernelnewbies

On 17/12/15 21:35, Kenneth Adam Miller wrote:
> Generally uio_dmem_genirq.c builds on top of uio.c, which provides a
> common module basis for isolating code common to the other specific
> modules. But for a specific purpose, uio_dmem_genirq.c has be either
> customized or extended in order that specific memory regions can be
> set as accessible. Most easily, this is done in a first come first
> serve approach by filling out the details (which exactly?) left
> missing in uio_dmem_genirq.c, and to start, that would be
> in uio_of_genirq_match
> <https://proxy-us.hide.me/go.php?u=zWvu%2Fc4k0RUgdQesK%2F26T4EuwcXktyOuOa%2F3x1F0nLo5r0d9WlQEzfN928BYniutwGWnnJXkaBWcsA6D&b=29>.
>
> Am I correct?

It's not always necessary to modify uio_dmem_genirq.

Certainly in cases where the hardware capability can be specified by a
device tree (e.g. ARM systems), it is possible to specify an address
space and an IRQ that can be immediately used from userspace with the
uio_dmem_genirq driver with no modifications.

Henry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151218/43ffd32f/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151218/43ffd32f/attachment.bin 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Customizing UIO mmap'ing
  2015-12-18 12:05 ` Henry Gomersall
@ 2015-12-18 14:15   ` Kenneth Adam Miller
  2015-12-18 14:20     ` Henry Gomersall
  0 siblings, 1 reply; 5+ messages in thread
From: Kenneth Adam Miller @ 2015-12-18 14:15 UTC (permalink / raw)
  To: kernelnewbies

On Fri, Dec 18, 2015 at 7:05 AM, Henry Gomersall <
henry.gomersall@smartacoustics.co.uk> wrote:

> On 17/12/15 21:35, Kenneth Adam Miller wrote:
>
> Generally uio_dmem_genirq.c builds on top of uio.c, which provides a
> common module basis for isolating code common to the other specific
> modules. But for a specific purpose, uio_dmem_genirq.c has be either
> customized or extended in order that specific memory regions can be set as
> accessible. Most easily, this is done in a first come first serve approach
> by filling out the details (which exactly?) left missing in
> uio_dmem_genirq.c, and to start, that would be in uio_of_genirq_match
> <https://proxy-us.hide.me/go.php?u=zWvu%2Fc4k0RUgdQesK%2F26T4EuwcXktyOuOa%2F3x1F0nLo5r0d9WlQEzfN928BYniutwGWnnJXkaBWcsA6D&b=29>
> .
>
> Am I correct?
>
>
> It's not always necessary to modify uio_dmem_genirq.
>
>
Is it correct though, that I can use another module to stack on top of
uio_dmem_genirq, and that the correct thing to modify is in fact the
variable I mentioned?


> Certainly in cases where the hardware capability can be specified by a
> device tree (e.g. ARM systems), it is possible to specify an address space
> and an IRQ that can be immediately used from userspace with the
> uio_dmem_genirq driver with no modifications.
>
>
This is not our case. I have to programmatically retrieve the regions when
the driver is loaded (I know that's just a matter of putting the right code
in the right callback), and allow that to serve as a match.


> Henry
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151218/947e24a7/attachment.html 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Customizing UIO mmap'ing
  2015-12-18 14:15   ` Kenneth Adam Miller
@ 2015-12-18 14:20     ` Henry Gomersall
  2015-12-18 14:51       ` Kenneth Adam Miller
  0 siblings, 1 reply; 5+ messages in thread
From: Henry Gomersall @ 2015-12-18 14:20 UTC (permalink / raw)
  To: kernelnewbies

On 18/12/15 14:15, Kenneth Adam Miller wrote:
>
> On Fri, Dec 18, 2015 at 7:05 AM, Henry Gomersall
> <henry.gomersall@smartacoustics.co.uk
> <mailto:henry.gomersall@smartacoustics.co.uk>> wrote:
>
>     On 17/12/15 21:35, Kenneth Adam Miller wrote:
>>     Generally uio_dmem_genirq.c builds on top of uio.c, which
>>     provides a common module basis for isolating code common to the
>>     other specific modules. But for a specific purpose,
>>     uio_dmem_genirq.c has be either customized or extended in order
>>     that specific memory regions can be set as accessible. Most
>>     easily, this is done in a first come first serve approach by
>>     filling out the details (which exactly?) left missing in
>>     uio_dmem_genirq.c, and to start, that would be
>>     in uio_of_genirq_match
>>     <https://proxy-us.hide.me/go.php?u=zWvu%2Fc4k0RUgdQesK%2F26T4EuwcXktyOuOa%2F3x1F0nLo5r0d9WlQEzfN928BYniutwGWnnJXkaBWcsA6D&b=29>.
>>
>>     Am I correct?
>
>     It's not always necessary to modify uio_dmem_genirq.
>
>
> Is it correct though, that I can use another module to stack on top of
> uio_dmem_genirq, and that the correct thing to modify is in fact the
> variable I mentioned? 

I don't know the answer to this. I'm pretty new to it myself :)

Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151218/22be26b1/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151218/22be26b1/attachment.bin 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Customizing UIO mmap'ing
  2015-12-18 14:20     ` Henry Gomersall
@ 2015-12-18 14:51       ` Kenneth Adam Miller
  0 siblings, 0 replies; 5+ messages in thread
From: Kenneth Adam Miller @ 2015-12-18 14:51 UTC (permalink / raw)
  To: kernelnewbies

On Fri, Dec 18, 2015 at 9:20 AM, Henry Gomersall <
henry.gomersall@smartacoustics.co.uk> wrote:

> On 18/12/15 14:15, Kenneth Adam Miller wrote:
>
>
> On Fri, Dec 18, 2015 at 7:05 AM, Henry Gomersall <
> henry.gomersall at smartacoustics.co.uk> wrote:
>
>> On 17/12/15 21:35, Kenneth Adam Miller wrote:
>>
>> Generally uio_dmem_genirq.c builds on top of uio.c, which provides a
>> common module basis for isolating code common to the other specific
>> modules. But for a specific purpose, uio_dmem_genirq.c has be either
>> customized or extended in order that specific memory regions can be set as
>> accessible. Most easily, this is done in a first come first serve approach
>> by filling out the details (which exactly?) left missing in
>> uio_dmem_genirq.c, and to start, that would be in uio_of_genirq_match
>> <https://proxy-us.hide.me/go.php?u=zWvu%2Fc4k0RUgdQesK%2F26T4EuwcXktyOuOa%2F3x1F0nLo5r0d9WlQEzfN928BYniutwGWnnJXkaBWcsA6D&b=29>
>> .
>>
>> Am I correct?
>>
>>
>> It's not always necessary to modify uio_dmem_genirq.
>>
>>
> Is it correct though, that I can use another module to stack on top of
> uio_dmem_genirq, and that the correct thing to modify is in fact the
> variable I mentioned?
>
>
> I don't know the answer to this. I'm pretty new to it myself :)
>

Well for any other readers of this conversation, compared to my previous
(perceived) requirements, I now only need to mmap a specific region of
hardware addresses - nothing about custom allocation within that region. I
can use /dev/mem, but that's perceived to be a potential security issue
that we want to keep mitigated. So, we have decided that a uio driver that
filters for the specific hardware address regions that we allow is
desirable. I think that uio_dmem_genirq would be the way to go about it,
but I am not sure there is any example that exists demonstrating how to
edit and then use it.


>
>
> Henry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151218/d0db70a9/attachment.html 

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-12-18 14:51 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-17 21:35 Customizing UIO mmap'ing Kenneth Adam Miller
2015-12-18 12:05 ` Henry Gomersall
2015-12-18 14:15   ` Kenneth Adam Miller
2015-12-18 14:20     ` Henry Gomersall
2015-12-18 14:51       ` Kenneth Adam Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.