How can I write a C program (in userspace) to call functions that are part of a kernel driver? If it's not possible to do directly, how else do I do it?
CONTEXT: I am trying to use the PWM pins of my single-board computer (Intel NUC DE3815TYBE) so that I can control fans. A linux driver called pwm_lpss allows control of these pins (driver developed by Intel, source code here). I have verified that this driver is installed by using the lsmod command. Here is the driver information after typing modinfo pwm_lpss:
filename: /lib/modules/3.19.0-25-generic/kernel/drivers/pwm/pwm-lpss.ko
license: GPL v2
author: Mika Westerberg <mika.westerberg#linux.intel.com>
description: PWM driver for Intel LPSS
srcversion: 44AA14AF3E2F96C813770A8
depends:
intree: Y
vermagic: 3.19.0-25-generic SMP mod_unload modversions
signer: Magrathea: Glacier signing key
sig_key: 6A:AA:11:D1:8C:2D:3A:40:B1:B4:DB:E5:BF:8A:D6:56:DD:F5:18:38
sig_hashalgo: sha512
So I know where the driver module is (the pwm-lpss.ko file) and I have the source code which I know has a function in it called pwm_lpss_config() that I'd like to use. How do I call the function from my userspace C program? How would I go about #including it? Or is this not possible to do from userspace?
Unfortunately Intel has provided zero documentation for how to use this driver. I thought drivers normally map their functionality to some user-accessible file. I was able to find some PWM-related files after some digging, but I haven't been able to find a file that looks like it can set PWM duty cycle/frequency.
It's a standard Linux PWM driver, so no special documentation is necessary.
Check the /sys/class/pwm/ directory. (/sys is the interface the kernel provides for access to its data structures. It just looks and acts like a filesystem.) You should have something like /sys/class/pwm/pwmchip0/. Each such directory corresponds to a PWM chip.
The directory will have the following entries. You may need superuser privileges to access these (as you wouldn't want everybody to mess with them):
npwm: Read this to find out how many PWM channels this chip has.
export: Write a channel number (0 to whatever-the-number-in-npwm-1) to make that channel available via this sysfs interface
unexport: Write a channel number to remove the channel from sysfs interface control
Each PWM channel exported to be used via the sysfs interface will show up as a subdirectory named pwmN, where N is the channel number. Here, you can read and write to entries
period: Total period (off + on) in nanoseconds.
duty_cycle: On time in nanoseconds. Must be less than period.
polarity: If the chip supports reversing the signal polarity, you can write inversed here to invert the polarity; normal is the default/normal polarity.
enable: 1 if enabled, 0 if disabled.
When reading or writing to these entries, no special locking is necessary. The kernel will receive all data in one write(), and return all data in one read() operation. When a write() succeeds, the kernel has applied the setting.
some ioctl ? The ioctl() function manipulates the underlying device parameters of special files.
Along the lines
fd = open("/dev/pwm0", O_RDONLY); // put whatever device you've got
if (ioctl(fd, STATUSGET, &status) == -1) // magic constant should be set
....
} else {
....
}
Related
I am writing a Linux kernel driver (kernel 4.9) for our custom setup.
We do use a ARM64 based board with a PCIe interface.
Connected to the interface we have an extension board with a FPGA on it.
At this moment I succeed at creating a device that registers my FPGA with some basic functions, like reading the version of the FPGA in a certain register in the FPGA.
In the FPGA we do have some additional "devices" like GPIO, memory regions ... that I would like to add as its own chardevice. We do have existing drivers for these.
Normally, Linux goes over the DTB and calls the correct driver for our FPGA, following the correct drivers for our child devices.
Now I would like to archieve the same with this PCIe interface. To do this, I look for a node in my DTB fpga and add its children.
for_each_available_child_of_node(np, nc) {
subdev = kzalloc(sizeof(*subdev), GFP_KERNEL);
list_add(&subdev->subdev_entry, &priv->subdev_list.subdev_entry);
...
}
list_for_each_entry(subdev, &priv->subdev_list.subdev_entry,
subdev_entry) {
ret = mfd_add_devices(priv->dev, PLATFORM_DEVID_NONE,
subdev->mfd_cell, 1, NULL, irq_base, NULL);
if (ret) {
dev_err(priv->dev, "Failed to add mfd cell\n");
goto err_mfd_add;
}
}
For some reason, the driver is not loaded for its children.
print's in the device drivers probe function shows nothing, not being called.
Added print's to the loops and it shows its children (all properties and values check out with what I set in the DTB).
Yes, the driver is compiled an available in the kernel.
I also tried building the driver as a kmod and load it that way, no change in behaviour. The output of lsmod shows the module is loaded but not used.
Somebody got an idea why my driver is not being loaded?
EDIT:
I also can see the "nodes" from my DTB that should be created as a chardevice.
They can be found in the expected location /sys/class/my_fpga/fpga/device/, in this case GPIO.
Under the GPIO folder I can see the driver_override (which is (null) ), modalias, power, sybsystem and uevent.
So my device (my_fpga) seems to be enumerated, only its children are not created.
A reboot does not solve it, nor a rescan of the PCIe-bus. The extension-board is powered via an external powersupply and is already configured before booting Linux
I have a motherboard with I/O pins and I have written a C library with functions to set and query the status of these I/O pins. Lets say the name of one of these functions is get_pin(int pin_no), and it returns the logical voltage of that pin. I would like to send a 1 pulse-per-second (PPS) signal to one of my pins and tell Linux's NTPD to calibrate based off this signal.
Is it possible to tell the NTPD to use one of these I/O pins as its PPS? If so, what is the approach to do this? Ie. Is it via config file or does it require modifying NTPD's source code? My early research seems to suggest the latter may be necessary.
Edit: I'm working with the ntpd on Centos
Does your kernel have PPS support?
$ grep PPS /boot/config-$(uname -r)
# PPS support
CONFIG_PPS=m
# CONFIG_PPS_DEBUG is not set
# PPS clients support
# CONFIG_PPS_CLIENT_KTIMER is not set
CONFIG_PPS_CLIENT_LDISC=m
CONFIG_PPS_CLIENT_PARPORT=m
CONFIG_PPS_CLIENT_GPIO=m
# PPS generators support
Is ldattach installed?
$ which ldattach
/usr/sbin/ldattach
You may not need ldattach. It was mentioned in the LinuxPPS installation instructions. However, it appears that it is only used for PPS sent over a serial line (e.g. RS-232).
Are the pps-tools installed?
$ which ppstest
/usr/bin/ppstest
Is the pps-gpio.ko module installed?
$ modinfo pps-gpio
filename: /lib/modules/4.4.0-38-generic/kernel/drivers/pps/clients/pps-gpio.ko
version: 1.0.0
license: GPL
description: Use GPIO pin as PPS source
author: James Nuss <jamesnuss#nanometrics.ca>
author: Ricardo Martins <rasm#fe.up.pt>
srcversion: D2C22B0A465DA63746EFB59
alias: of:N*T*Cpps-gpio*
depends: pps_core
intree: Y
vermagic: 4.4.0-38-generic SMP mod_unload modversions
You can tell the kernel that a GPIO pin will be used as a PPS signal by adding something like this to your kernel line in your GRUB config:
dtoverlay=pps-gpio,gpiopin=18
You will need to change "18" to the GPIO pin you are using.
You will need to add a couple of lines like this to your ntp.conf:
server 127.127.22.1 # ATOM(PPS)
fudge 127.127.22.1 flag3 1 # enable PPS API
References:
http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm
http://linuxpps.org/wiki/index.php/Main_Page
http://rdlazaro.info/compu-Raspberry_Pi-RPi-stratum0.html
http://doc.ntp.org/4.1.1/refclock.htm
http://doc.ntp.org/4.1.1/driver22.htm
One pulse per second calibration signal will also require reading input pin exactly at 1 second for calibration. Polling will not serve as timer execution may be differed by OS on high priority work.
Same way using interrupt on change* for this pin hooked with calibrate function will also not grantee 1 PPS execution of calibration method due to interrupt processing delays like say when a higher priority interrupt occurs.
If I understood question correctly, you are using something like Raspberry and wish to syncronize your system by another controller by receiving some sequence of logical 1s that will mean, for instance, time teac for your board?
The only one thing I do not understand is why do you need ntp daemon for that. Isn't it better to create a static time_t variable that will increment upon each teac receipt?
If you wish to syncronize some external devices later and the board acts as a time server - just adjust system date each time when the difference between your static variable and time(0) value will be greater than defined value.
I am learning about the driver and looking into the watchdog driver code where some value is being written to /sys/devices/virtual/wdc_per now I guess this is the logic how driver gets its value from userspace and exposed file in user space is
"sys/devices/virtual/wdc_per"
But now how actually this value from wdc_per is reached to driver, there must some callback maintained
In My case its GPIO based Watchdog driver and gpio_wdt.c may be having this callback.
But I really could not figure out how it actually happens
Anybody can help me find out this userspace to kernel space link.
First of all, this driver, gpio_wdt.c, doesn't seem to exist in the mainline kernel as of this date, so it's hard to comment it.
Sysfs (usually mounted at /sys) is actually very easy to use. This is a great example of how to create Sysfs attributes. Basically, you create attributes (will become the Sysfs file names) and register them with two defined operations (callbacks): store and show, which are the equivalent of resp. write and read. The show callback is called everytime the Sysfs file (attribute) is read and store when it's written.
When writing a device driver that belongs to an existing class (most likely your situation), you will rarely need to do that yourself. This is because the standard Linux device classes already have a working set of Sysfs attributes that your driver will use more or less indirectly.
For example, the leds class (LED devices), of which you will find the devices in /sys/class/leds, has a bunch of Sysfs attributes per LED so that a user may read/modify them from userspace (brightness, maximum brightness, trigger, etc.). Now, if you look at LED specific drivers in /drivers/leds, you won't find manual Sysfs attributes creations. You will find, however, a call to led_classdev_register when the driver is probed, which takes a struct led_classdev* as a parameter. This structure has a brightness_set callback member the specific driver needs to provide. When a user writes to /sys/class/leds/whatever-led/brightness, the leds class' store Sysfs callback gets called which in turn calls the specific driver's brightness_set callback.
My point is: make sure you really know your device class before manually adding Sysfs attributes. Anyway, when submitting your driver to the LKML, you will know fast enough if it was a good decision.
I need a method to perform the following task, suppose if I have a computer with k (k is large) number of Ethernet interfaces. I want to have a method to identify which identifier (em0) is assigned to which physical interface.
The only "easy" method that I came up is to blink the LED light on the physical interface.
For example
etherblink em0
Would flash the link or the activity LED on the physical Ethernet interface that is assigned to em0.
I know on linux there is the ethertool, but that doesn't work with FreeBSD. As well as there is the LED driver on FreeBSD, but that only support limited number of Ethernet modules.
Any ideas? I thought about binding a socket to the interface and write to the socket, but that didn't work.
C or Perl
Tough I have not done this, but, according to FreeBSD handbook, it's possible to bind specific driver node to specific hardware IRQ using kernel configuration hints. See device.hints(5) and FreeBSD network setup to see how to locate each Ethernet device IRQ.
Assume the interface in question is fxp0... run this as root
use strict;
my $intf = "fxp0";
while (1) {
foreach my $state (qw/up down/) {
system("ifconfig $intf $state\n");
sleep 3;
}
}
I assume you won't care about transfering data through the interface while it's blinking...
Sadly I did not find a general solution to this problem, however, from my research (by reading the change log of FreeBSD 8.2, and from the forums) It seems that:
"some cards blink the LEDs on access, so pings could make a repeated pattern.
The LEDs might even go off if the card is downed with ifconfig(8)."
Particularly em and igb interfaces, as stated by:
"The em(4) and igb(4) drivers now support the led(4) interface via /dev/led/emN and
/dev/led/igbN for identification LED control. The following command line makes the
LED blink on em0:[r211241]" (FreeBSD 8.2 Release changelog)
However I do not have the hardware to test this. What I did end up doing was rewritten the Ethernet driver for the interface that I am using to support the LED hardware feature.
I'm customising Linux for an ARM9 Atmel AT91SAM960 board.
In the device file Atmel named all the USART the same atmel_usart. Of course with id enumeration:
static struct platform_device at91sam9260_uart0_device = {
.name = "atmel_usart",
.id = 1,
.dev = { ...}
}
According to the Linux Device model, all these devices (5 UARTS on a SAM9260) would be bind to the driver named atmel_usart.
I don't want to set a TTYS driver on all UARTS which will be registerd. I have several own drivers which serve for different specialised purposes (LON, RS-485 etc.) I want the control which driver does serve a certain USART. So what could I do:
The Atmel device files are unsatisfiable and I can do it better. So I rename (patch) the devices in the device file. However, in case I want a TTYS driver on UART4 I would be in trouble.
I manipulate (patch) the device file,
so that I'm able the access the
structures platform_device. I could
change their names before I would
register them. But as far as I
understood the idea of the Linux Driver Model,
devices should be
registered early during boot-up but the binding to a driver follows .... later.
I could write a driver, which has an
alias name and which would be binded
to a specific bus_Id ->
atmel_usart.4. Can I really?
What solutions else exist. I want to touch a minimal set of Kernel files but I want all the freedom possible?
Addendum what freedom means to me: I can specify at runtime how the UARTS can be used
with the Atmel-Serial driver (ttyS)
with my own drivers
It means also, that changes to the kernel source are minimal.
I built my own line discipline drivers. You can build them as kernel modules and attach them to the UARTs at runtime. No changes to the Linux source are necessary.
Any funny timing or control stuff can be done through ioctl(). Specifically, I implemented a timing-sensitive RS-485 protocol in this way.
When I did this (Linux 2.6.17) there was no dynamic registration mechanism, so I overwrote the existing line disciplines. The Linux code is (was) pretty straightforward, and I was satisfied that this would be a safe thing to do.
Your problem is quite easily solved. The 5 UART devices are presently registered at kernel startup and their function is locked. This is now how it normally works for PCI or USB devices, right? So what you need to do is pull the device registration out of the startup code and register it dynamically. You can even register/unregister as needed.
at91_register_uart() is being called from your board file for every UART that needs registered. at91_add_device_serial() will then platform_device_register all those you what setup. One solution is to let at91_register_uart() be called for all 5 UARTS, but then remove the call to at91_add_device_serial() from your board. You can then make it an exported function that can be called by your loadable drivers. You can even add an argument to it (int) so that instead of looping on all UARTS, you can select which ones to register individually. You can also mirror this function by making one that unregisters the devices.
NOTE: I think you'll need to always leave one UART dedicated as your console, if you are using one that way. You could probably hide that in the exported function by only allowing index 0->3 as in input and then mapping 0->3 to 0-4, skipping the UART that you want to use for console.