writing data to debugfs --- from a device driver - linux-kernel

With proc we can easily use read & write system call as shown in this example.
write on /proc entry through user space
But i am working on passing information from driver to user-space using debugfs.
I am able to find these two example code. Here application is able to read and write to debugfs file using mmap() system call.
http://people.ee.ethz.ch/~arkeller/linux/code/mmap_simple_kernel.c
http://people.ee.ethz.ch/~arkeller/linux/code/mmap_user.c
But suppose in my case requirement for communicating using Debugfs file with device driver:
user-space application <-------> debugfs file <-------> Device driver
So can i use same code mmap_simple_kernel.c inside my --->> device driver code --->> and transfer data to debugfs directly from driver ? But in this case there will be two file_operations structures inside my driver will it cause some problem ? Is it right approach ?
Or just like application is following process in -- mmap_user.c --- same process -- i follow in my device driver program. And keep mmap_simple_kernel.c as seprate module for debugfs entry ?

You can take a look at how kmemleak uses debugfs in mm/kmemleak.c:
static const struct seq_operations kmemleak_seq_ops = {
.start = kmemleak_seq_start,
.next = kmemleak_seq_next,
.stop = kmemleak_seq_stop,
.show = kmemleak_seq_show,
};
static int kmemleak_open(struct inode *inode, struct file *file)
{
return seq_open(file, &kmemleak_seq_ops);
}
static int kmemleak_release(struct inode *inode, struct file *file)
{
return seq_release(inode, file);
}
static ssize_t kmemleak_write(struct file *file, const char __user *user_buf,
size_t size, loff_t *ppos)
{...}
static const struct file_operations kmemleak_fops = {
.owner = THIS_MODULE,
.open = kmemleak_open,
.read = seq_read,
.write = kmemleak_write,
.llseek = seq_lseek,
.release = kmemleak_release,
};
dentry = debugfs_create_file("kmemleak", S_IRUGO, NULL, NULL,
&kmemleak_fops);

This question is the top search result in Google for mmap debugfs. I am adding here an important information. According to this https://lkml.org/lkml/2016/5/21/73 post debugfs_create_file() in the kernel 4.8.0 or higher will ignore .mmap field in the struct file_operations
Use debugfs_create_file_unsafe() as a workaround

Related

I2C read write functions in linux

How is the read and write functions in I2C drivers for linux are communicated to linux? In all the drivers for devices on I2C in the linux source, the file_operations structure is not used to tell the kernel about the functions. How is the various functionalities communicated to kernel, so they can be called from user space without using file_operations?
I2C driver in linux support the file operation as well. Because when you start open i2c from your application;
snprintf(filename, 19, "/dev/i2c-%d", adapter_nr);
file = open(filename, O_RDWR);
It will call to the i2c-dev.c file in linux kernel
static int i2cdev_open(struct inode *inode, struct file *file);
static const struct file_operations i2cdev_fops = {
.owner = THIS_MODULE,
.llseek = no_llseek,
.read = i2cdev_read,
.write = i2cdev_write,
.unlocked_ioctl = i2cdev_ioctl,
.open = i2cdev_open,
.release = i2cdev_release,
};
But if you want to read and write from the user space without file_operatoin then you can use the kobject in your driver for read and write through sysfs.
For reading from the user space:
static ssize_t module_show_status(struct kobject *kobj,struct kobj_attribute *attr,char *buf);
For writing from the user space
static ssize_t module_store__status(struct kobject *kobj,struct kobj_attribute *attr,const char *buf, size_t count);
But before using these APIs you need to create the kboject in your driver.

Registering Platform Device with info from Device Tree

I am using Petalinux for a Xilinx Zynq application, and I am new to kernel driver development.
I created a kernel module for a platform driver for an AXI FIFO interface. The devices seems to be recognised from the device tree using the .of_match_table, since I can see the correct memory space reserved with cat /proc/iomem .
If I search for the driver name xxx I get
./lib/modules/4.4.0-xilinx/extra/xxx.ko
./sys/bus/platform/drivers/xxx
./sys/module/xxx
./sys/module/xxx/drivers/platform:xxx
I found the device under /sys/bus/platform/devices/43c00000.axi_xxxx but still can't access it or see it under /dev/.
How do I register device so that I can open it from my user space app?.
Do I need to allocate memory for it and then register a new device using platform_device_register(pdev)?
Thanks
You need to register your device in a framework to get a device file created.
I would suggest registering a miscdevice in your case. It simply registers a character device.
static struct miscdevice miscdev;
static ssize_t myaxi_read(struct file *file, char __user *buf,
size_t sz, loff_t *ppos)
{
// Do something
}
static ssize_t myaxi_write(struct file *file, const char __user *buf,
size_t sz, loff_t *ppos)
{
// Do something
}
static const struct file_operations myaxi_fops = {
.owner = THIS_MODULE,
.write = myaxi_write,
.read = myaxi_read,
};
In your probe:
miscdev.minor = MISC_DYNAMIC_MINOR;
miscdev.name = "myaxi";
miscdev.fops = &myaxi_fops;
misc_register(&miscdev);
You can read more about linux kernel driver development and the device model at http://free-electrons.com/doc/training/linux-kernel/linux-kernel-slides.pdf

How to attach file operations to sysfs attribute in platform driver?

I wrote a platform driver for a peripheral we developed and would like to expose some configuration options to the sysfs. I have managed to create the appropriate files using attribute structs (see below) and sysfs_create_file in the probe function, but I can't figure out how to attach the show/store functions to the structs in a platform driver.
Most resources I found online used a device_attribute struct or something similar to create their files, is that also appropriate here? Is there another way to do this for a platform driver?
My attribute struct looks like this:
struct attribute subkey_attr = {
.name = "subkeys",
.mode = S_IWUGO | S_IRUGO,
};
And I register the file using this call:
riddler_kobject = &pdev->dev.kobj;
ret_val = sysfs_create_file(riddler_kobject, &subkey_attr);
It boils down to next:
reuse existing kobject from struct device (from your struct platform_device) for sysfs_create_group() (instead of creating your own kobject)
use DEVICE_ATTR() to declare struct device_attribute instead of regular __ATTR(), which creates struct kobj_attribute.
Here is how I created sysfs attributes for my platform driver.
Create structure you'll be using as private data in show() / store() operations for your sysfs attribute (file). For example:
struct mydrv {
struct device *dev;
long myparam;
};
Allocate this structure in your driver's probe():
static int mydrv_probe(struct platform_device *pdev)
{
struct mydrv *mydrv;
mydrv = devm_kzalloc(&pdev->dev, sizeof(*mydrv), GFP_KERNEL);
mydrv->dev = &pdev->dev;
platform_set_drvdata(pdev, mydrv);
...
}
Create show() / store() functions:
static ssize_t mydrv_myparam_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct mydrv *mydrv = dev_get_drvdata(dev);
int len;
len = sprintf(buf, "%d\n", mydrv->myparam);
if (len <= 0)
dev_err(dev, "mydrv: Invalid sprintf len: %d\n", len);
return len;
}
static ssize_t mydrv_myparam_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t count)
{
struct mydrv *mydrv = dev_get_drvdata(dev);
kstrtol(buf, 10, &mydrv->myparam);
return count;
}
Create device attribute for those functions (right after those functions):
static DEVICE_ATTR(myparam, S_IRUGO | S_IWUSR, mydrv_myparam_show,
mydrv_myparam_store);
Declare attributes table (listing in fact sysfs files for you driver):
static struct attribute *mydrv_attrs[] = {
&dev_attr_myparam.attr,
NULL
};
Declare attribute group (specifying in fact sysfs directory for your driver):
static struct attribute_group mydrv_group = {
.name = "mydrv",
.attrs = mydrv_attrs,
};
static struct attribute_group *mydrv_groups[] = {
&mydrv_group,
NULL
}
which can be actually replaced with one line:
ATTRIBUTE_GROUPS(mydrv);
Create sysfs directory and files in your driver's probe() function:
static int mydrv_probe(struct platform_device *pdev)
{
int ret;
...
ret = sysfs_create_group(&pdev->dev.kobj, &mydrv_group);
if (ret) {
dev_err(&pdev->dev, "sysfs creation failed\n");
return ret;
}
...
}
Remove your sysfs files in your driver's remove() function:
static int mydrv_remove(struct platform_device *pdev)
{
sysfs_remove_group(&pdev->dev.kobj, &mydrv_group);
...
}
Race condition note
As #FranzForstmayr correctly pointed out, there may be race condition when adding sysfs files with sysfs_create_group() in mydrv_probe(). That's because user-space can be already notified that those files exist before mydrv_probe() called (where those files are actually being created by sysfs_create_group() function). This issue covered in details in "How to Create a sysfs File Correctly" article by Greg Kroah-Hartman.
So in our case of platform_device, instead of calling sysfs_create_group() (and its counterpart sysfs_remove_group()), you can use default attribute group. To do so, you need to assign corresponding .groups field of your struct device to your attribute groups variable:
static int mydrv_probe(struct platform_device *pdev)
{
...
pdev->dev.groups = mydrv_groups;
...
}
DISCLAIMER: I didn't test this code, though it should work, because of this code.
See [1,2,3] links for more insights on mentioned race condition.
For more examples, run next command in kernel source directory:
$ git grep -l --all-match -e platform_device -e attribute -e '\.groups =' -- drivers/
Also you can search by "default attribute" in commit messages:
$ git log --no-merges --oneline --grep="default attribute" -- drivers/
Some commits I found this way: [4,5,6,7].
References
[1] My attributes are way too racy, what should I do?
[2] PATCH: sysfs: add devm_sysfs_create_group() and friends
[3] [GIT PATCH] Driver core patches for 3.11-rc2
[4] commit 1
[5] commit 2
[6] commit 3
[7] commit 4
Not enough reputation to post a comment, but I just want to comment on the default attribute group note from the accepted answer.
My understanding is that this should not be added in the probe function, as given in the example, but instead should be set in the device struct, (or device_driver, class, or bus depending on your driver) usually defined at the end of your file.
For example:
static struct device iio_evgen_dev = {
.bus = &iio_bus_type,
.groups = iio_evgen_groups,
.release = &iio_evgen_release,
};
from this example
Strangely, according to this it doesn't work correctly when using DEVICE_INT_ATTR to create the attribute, so not sure what that's all about.
Also, I'm not 100% sure, but I think that this is invoked when the driver is loaded, not when the device is probed.
This is an addition to Sam Protsenko's and Anthony's answers
If you create device attributes via the DEVICE_ATTR macros then you have to register the attribute groups (mydrv_groups) in the .dev_groups instead of the .groups field.
static struct device iio_evgen_dev = {
.bus = &iio_bus_type,
.dev_groups = iio_evgen_groups, // .dev_groups for DEVICE_ATTR
.groups = another_attr_group, // .groups for DRIVER_ATTR
.release = &iio_evgen_release,
};
Then the attributes are automatically registered correctly without setting up anything in the probe/remove functions, as described in Greg Kroah-Hartman's article.
Assume that the module has been loaded into the kernel and the driver is registered in
/sys/bus/platform/drivers/mydrv
every device instances will be a subdirectory of the driver's folder like
/sys/bus/platform/drivers/mydrv/mydrv1
/sys/bus/platform/drivers/mydrv/mydrv2
Registering attributes in the .groups field creates the attributes in the driver folder.
Registering attributes in the .dev_groups field creates the attributes in the device's instance folder.
mydrv
├── driver_attr1
├── driver_attr2
└── mydrv1
├── device_attr1
└── device_attr2
The show/store functions of the attributes in the .groups field do not have access to the driver data set via platform_set_drvdata(pdev, mydrv).
At least not by accessing it via dev_get_drvdata(dev).
Accessing the driver data via dev_get_drvdata(dev) returns NULL and dereferencing it will result in a kernel oops.
In turn, he show/store functions of the attributes in the .dev_groups field have access to the driver data via
struct mydrv *mydrv = dev_get_drvdata(dev);

using system call in Linux kernel file

I am implementing a custom process scheduler in Linux. And I want to use a system call to record my program so that I can debug easily.
The file I write is
source code : linux-x.x.x/kernel/sched_new_scheduler.c
In sched_new_scheduler.c could I use syscall(the id of the system call, parameter); directly? It seems syscall(); is used with #include<sys/syscalls.h> in C program, but the ".h" can not be found in the kernel/.
I just want to know how my program executes by recording something, so could I directly write printk("something"); in sched_new_scheduler.c ? Or try a correct way to use system call?
System call look like wrapper around other kernel function one of ways how to use syscall inside kernel is find sub function for exact system call. For example:
int open(const char *pathname, int flags, mode_t mode); -> filp_open
////////////////////////////////////////////////////////////////////////////////////////////////
struct file* file_open(const char* path, int flags, int rights)
{
struct file* filp = NULL;
mm_segment_t oldfs;
int err = 0;
oldfs = get_fs();
set_fs(get_ds());
filp = filp_open(path, flags, rights);
set_fs(oldfs);
if(IS_ERR(filp)) {
err = PTR_ERR(filp);
return NULL;
}
return filp;
}
ssize_t write(int fd, const void *buf, size_t count); -> vfs_write
////////////////////////////////////////////////////////////////////////////////////////////////
int file_write(struct file* file, unsigned long long offset, unsigned char* data, unsigned int size)
{
mm_segment_t oldfs;
int ret;
oldfs = get_fs();
set_fs(get_ds());
ret = vfs_write(file, data, size, &offset);
set_fs(oldfs);
return ret;
}
A system call is supposed to be used by an application program to avail a service from kernel. You can implement a system call in your kernel module, but that should be called from an application program. If you just want to expose the statistics of your new scheduler to the userspace for debugging, you can use interfaces like proc, sys, debugfs etc. And that would be much more easier than implementing a system call and writing a userspace application to use it.

Memory limit for mmap

I am trying to mmap a char device. It works for 65536 bytes. But I get the following error if I try for more memory.
mmap: Resource temporarily unavailable
I want to mmap 1MB memory for a device. I use alloc_chrdev_region, cdev_init, cdev_add for the char device. How can I mmap memory larger than 65K? Should I use block device?
Using the MAP_LOCKED flag in the mmap call can cause this error. The used mlock can return EAGAIN if the amount of memory can not be locked.
From man mmap:
MAP_LOCKED (since Linux 2.5.37) Lock the pages of the mapped region
into memory in the manner of mlock(2). This flag is ignored in older
kernels.
From man mlock:
EAGAIN:
Some or all of the specified address range could not be
locked.
Did you implement *somedevice_mmap()* file operation?
static int somedev_mmap(struct file *filp, struct vm_area_struct *vma)
{
/* Do something. You probably need to use ioremap(). */
return 0;
}
static const struct file_operations somedev_fops = {
.owner = THIS_MODULE,
/* Initialize other file operations. */
.mmap = somedev_mmap,
};

Resources