Freescale Semiconductor SEC2SWUG 6Linux Environment

SEC 2.0 Reference Device Driver User’s Guide, Rev. 0

Freescale Semiconductor PRELIMINARY—SUBJECT TO CHANGE WITHOUT NOTICE 39

Linux Environment

6Linux Environment

This section describes the driver's adaptation to and interaction with the Linux operating system as applied to PPC

processors

The SEC2 driver installs into Linux as a loadable module. To build the driver as a module, it must be installed into

the kernel source tree to be included in the kernel buil d process . The makefile included wit h the distribut ion ass umes

this inclusion. As delivered, this directory is defined as [kernelroot]/drivers/sec2.

Once the driver source is installed, and the kernel sourc e (and modules) ar e buil t, module depende ncy lis ts up dated,

and the built objects are installed in the target filesystem , the driver, (named sec2drv.o) is ready for loading when

needed.

Kernel processes may call the driver's functionality direc tly. On the other hand, user processes must use the kernel's

I/O interface to make driver requests. The only way for user processes to do this it to open the device as a file with

the open() system call to get a file descriptor, and then make requests t hrough ioctl(). Thus the sys tem will need

a device file created to assign a name to the device.

The driver functions as a char device in the target system. As shipped, the driver assumes that the device major

number will be assigned dynamically, and that the minor number will always be zero, since only one instance of the

driver is supported.

Creation of the device's naming inode may be done manually in a development setting, or may be driven by a script

that runs after the driver module loads, and before any user attempts to open a path to the driver. Assuming the

module loaded with a dynamically assigned major number of 254 (look for sec2 in /proc/devices), then the

shell command to accomplish this would normally appear as:

$ mknod c 254 0 /dev/sec2

Once this is done, user tasks can make requests to the driver under the device name /dev/sec2.

Operation of the SEC2 device under kernel mode is relatively straightforward. Once the driver module has loaded,

which will initialize the device, direct calls to the ioctl() entry (named SEC2_ioctl in the driver) can be made,

the first two arguments may effectively be ignored.

In kernel mode, request completion may be handled through the standard use of notif ication callba cks in the reque st.

The example suite available with the driver shows how this may be acco m p lish ed ; this s uite u se s a mutex tha t the

callback will release in order to allow the request to complete, although the caller may make use of any other type

of event mechanism that suits th eir preference.

Logical to physical memory space translation is handled internal to the driver.