* 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.