Customizing UIO mmap'ing
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%2F3...> . Am I correct?
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%2F3...>.
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
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%2F3...> .
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/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%2F3...>.
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
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@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%2F3...> .
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
participants (2)
-
Henry Gomersall -
Kenneth Adam Miller