Experimental Physics and
Industrial Control System

On 12/4/22 02:39, Perez Juarez, Emilio (DLSLtd, RAL, LSCI) via Tech-talk wrote:
> Hi Lin Wang and thanks for sharing,
>
> I have some comments/questions:
>
>   * Is there a reason why you prefer to use ioctl for register access instead of mmap and letting userspace access directly?
>   * I know security is usually not a priority, but I've noticed you don't check/validate the register offset passed in the ioctl syscall, which means it could give access to other resources (memory or I/O)
>   * You might want to provide a fallback path when the target system doesn't have your kernel module installed, in which case, you can get register access by mmap'ing /sys/bus/pci/devices/<X>/resource<Y>, where <X> is the domain:bus:devices.function of your device and <Y> is the BAR number you want to access
>   * I noticed you dereference a volatile pointer to access the registers, in kernel space I'd recommend using the functions ioread<X> or iowrite<X> instead, where <X> is the access size (8, 16 or 32). This will make code more portable.

Sorry, I didn't notice this thread sooner.

My devlib2 support module does just what is described, and is portable
across Linux, RTEMS, and vxWorks.

https://epics.sourceforge.net/devlib2/

https://github.com/epics-modules/devlib2

This includes device support for simple register operations.

https://epics.sourceforge.net/devlib2/exploreapp.html

No DMA support, but there is limited support for interrupts if a
device supports the standard INTx Disable bit in the PCI_CONFIG
register (not to be assumed).

https://epics.sourceforge.net/devlib2/exploreapp.html#exploreirq


> I hope any of that was useful,
>
> Kind Regards,
> Emilio
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Wang, Lin via Tech-talk <tech-talk at aps.anl.gov>
> *Sent:* 02 December 2022 10:15
> *To:* tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
> *Subject:* A simple EPICS driver example for PCI devices using asynPortDriver on Linux
>
> Dear all,
>
>
> A simple EPICS driver example for PCI devices using asynPortDriver on Linux is shared in the following GitHub link in case somebody might be interested,
>
> https://github.com/wanglin86769/cpciEpicsApp
>
>
> This is an EPICS IOC developed for the LLRF system of a small-scale accelerator facility at CSNS campus. The LLRF board is a customized cPCI FPGA board with PCI 9056 bridge, the control interface is merely register access plus waveform read with 1 second update period, no interrupt or DMA is needed.
>
>
> The Linux driver part is implemented as kernel module rather than UIO (Userspace I/O). This example is only useful for simple customized PCI devices that does not need interrupt and DMA, and only one MMIO (Memory mapped I/O) BAR is used to access the FPGA registers.
>
>
> This is my first assignment to control PCI under Linux rather than vxWorks, any suggestion is appreciated.
>
>
>
> Regards,
>
> Lin Wang
>
> Staff Engineer
>
> Controls Group, Accelerator System Division, CSNS (China Spallation Neutron Source)
>
> IHEP (Institute of High Energy Physics), Chinese Academy of Science
>
> --
>
> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>