I am moving userspace sysfs interaction to the "/dev" using miscregister using ioctl method.
Can we resolve client structure(struct i2c_client) from Inode of please somebody tell how to get client structure inside ioctl. I need to do i2c transfer inside ioctl.
I referred this link :
http://stackoverflow.com/questions/2635038/inode-to-device-information
but coudln get any answer.
please someone give solution.
while you open your device in kernel using your open function. (this part of code is copied from one of the mainline drivers (drivers/i2c/i2c-dev.c) to make things easy for you)
my_i2c_device_open(struct inode *inode, struct file *file)
{
unsigned int minor = iminor(inode);
struct i2c_client *client;
struct i2c_adapter *adap;
struct i2c_dev *i2c_dev;
i2c_dev = i2c_dev_get_by_minor(minor);
if (!i2c_dev)
return -ENODEV;
adap = i2c_get_adapter(i2c_dev->adap->nr);
if (!adap)
return -ENODEV;
client = kzalloc(sizeof(*client), GFP_KERNEL);
if (!client) {
i2c_put_adapter(adap);
return -ENOMEM;
}
snprintf(client->name, I2C_NAME_SIZE, "i2c-dev %d", adap->nr);
client->adapter = adap;
file->private_data = client;
return 0;
}
when you call ioctl you can retrieve the i2c_client from the file pointer of your device:
static long my_i2c_device_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
struct i2c_client *client = file->private_data;
}
Hope this makes your life easy.'
This reference might help:
Reason to pass data using struct inode and struct file in Linux device driver programming
You build yourself a structure equivalent with "struct scull_dev" in the example above and you store there a reference to the i2c_client structure. In the IOCTL function you can retrieve later on the main control structure and the reference to the i2c_client through container_of.
Related
I'm not sure what I'm doing incorrectly but it's time for some extra eyes. I make a device with device_create() providing some "extra data" as follows:
pDevice = device_create(ahcip_class, NULL, /*no parent*/
MKDEV(AHCIP_MAJOR, AHCIP_MINOR + i), &mydevs[i],
DRIVER_NAME "%d", AHCIP_MINOR + i);
Expecting that my sysfs attribute function is going to take a pointer to the struct kobject member of struct device I do the following with my attribute function
static ahcip_dev *get_ahcip_dev(struct kobject *ko)
{
ahcip_dev *adev = NULL;
struct device *pdev = container_of(ko, struct device, kobj);
if (!pdev) {
pr_err("%s:%d unable to find device struct in kobject\n",
__func__, __LINE__);
return NULL;
}
/* some debugging stuff */
pr_info("%s:%d mydevs[0] %p\n", __func__, __LINE__, mydevs);
pr_info("%s:%d mydevs[1] %p\n", __func__, __LINE__, mydevs+1);
pr_info("%s:%d mydevs[0].psysfs_dev %p\n", __func__, __LINE__,
mydevs->psysfs_dev);
pr_info("%s:%d mydevs[1].psysfs_dev %p\n", __func__, __LINE__,
(mydevs + 1)->psysfs_dev);
pr_info("%s:%d pdev %p\n", __func__, __LINE__, pdev);
adev = (ahcip_dev*)dev_get_drvdata(pdev);
/* return the pointer anyway, but if it's null, print to klog */
if (!adev)
pr_err("%s:%d no ahcip_dev, private driver data is NULL\n",
__func__, __LINE__);
return adev;
}
static ssize_t pxis_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buff)
{
u32 pi = 0;
ahcip_dev *adev = get_ahcip_dev(kobj);
/* get_ahcip_dev() will print what happened, this needs to return
* error code
*/
if (!adev)
return -EIO;
pi = adev->port_index;
return sprintf(buff, "%08x\n", get_port_reg(adev->hba->ports[pi], 0x10));
}
The output (condensed) from the above function shows:
get_ahcip_dev:175 mydevs[1].psysfs_dev ffff88011b2b4800
get_ahcip_dev:176 pdev ffff88011b2b47f0
pdev in this case should point to the same memory location as mydevs[1].psysfs_dev but it's 16 bytes "earlier". What am I doing wrong?
I don't like to answer my own questions but this seems appropriate in this case. The root of the problem was a faulty assumption of what the attribute function needed to process. Attribute functions have this prototype you can view in context here
ssize_t (*show)(struct kobject *, struct attribute *,char *);
ssize_t (*store)(struct kobject *,struct attribute *,const char *, size_t);
Since the device_create() function returns a struct device object defined as follows (excerpt only, see full def here)
struct device {
struct device *parent;
struct device_private *p;
struct kobject kobj;
...
}
I assumed that it was this pointer that my attribute function must process. Reading through the description of the problem shows that when I used the container_of macro to get what I thought was the address of the containing struct device I was 16 bytes "to early." Notice, the first two fields of this structure are pointers. On a 64 bit system, which mine is, this is 16 bytes.
Because the function prototypes are defined as shown above, I assumed I was getting a reference to the kobj field. Instead, I was getting the actual struct device object. In other words, I was getting the address I wanted upon function entry and was still trying to find it.
Something about this may be documented in the labyrinth of Linux kernel documentation. If anyone knows of it, please put a link here. I read much but didn't see this one coming. I hope this question and answer helps some other kernel newbie.
Your example did not show how you created the sysfs attribute nor how your pxis_show() function was associated with it. Since you're trying to connect this attribute to a struct device, might you happen to be calling device_create_file() to create the sysfs node? If so, examining the callback prototypes of struct device_attribute might make more sense. You will see that the show/store callbacks look like:
ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
ssize_t (*store)(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count);
In which case that might better explain your extra offset issue--the first parameter is actually already pointing to your struct device, and not the embedded kobj member, so that performing a container_of() will take you back an additional 16 bytes.
You might be confusing the device_attribute callbacks with the struct sysfs_ops format, as they look similar, but notice the parameter types are different. In fact, there is a mapping from sysfs_ops to struct device_attribute as can be seen with the wrapper functions dev_attr_show and dev_attr_store as can be found here
I'm working on a driver in Linux. I'm working on getting some /sys file attributes in place that will make things nicer. In delivering what these attributes are to tell, the attribute functions must have access to some data that's stored by the driver. Because of how things appear to be made and stored, I thought I could use the device_private *p member of the struct device that comes from device_create(). Basically, it's like this:
for (i = 0; i < total; i++) {
pDevice = device_create(ahcip_class, NULL, /*no parent*/
MKDEV(AHCIP_MAJOR, AHCIP_MINOR + i), NULL, /*no additional info*/
DRIVER_NAME "%d", AHCIP_MINOR + i);
if (IS_ERR(pDevice)) {
ret = PTR_ERR(pDevice);
printk(KERN_ERR "%s:%d device_create failed AHCIP_MINOR %d\n",
__func__, __LINE__, (AHCIP_MINOR + i));
break;
}
mydevs[i].psysfs_dev = pDevice;
ret = sysfs_create_group(&pDevice->kobj, &attr_group);
if (!ret) {
pr_err("%s:%d failed in making the device attributes\n",
__func__, __LINE__);
goto build_udev_quick_out;
}
}
This doesn't yet show the assignment into the device_private pointer, but that's where I'm headed. Each new device made under this class will need the same attributes thus the group. Here's my single attribute that I'm starting with for "proof of concept"
static ahcip_dev *get_ahcip_dev(struct kobject *ko)
{
ahcip_dev *adev = NULL;
struct device *pdev = container_of(ko, struct device, kobj);
if (!pdev) {
pr_err("%s:%d unable to find device struct in kobject\n",
__func__, __LINE__);
return NULL;
}
/* **** problem dereferencing p **** */
adev = (ahcip_dev*)pdev->p->driver_data;
/* return the pointer anyway, but if it's null, print to klog */
if (!adev)
pr_err("%s:%d no ahcip_dev, private driver data is NULL\n",
__func__, __LINE__);
/* **** again problem dereferencing p **** */
return pdev->p->(ahcip_dev*)driver_data; // <--- problem here
}
static ssize_t pxis_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buff)
{
u32 pi = 0;
ahcip_dev *adev = get_ahcip_dev(kobj);
/* get_ahcip_dev() will print what happened, this needs to return
* error code
*/
if (!adev)
return -EIO;
pi = adev->port_index;
return sprintf(buff, "%08x\n", get_port_reg(adev->hba->ports[pi], 0x10));
}
I figured that, since device_create() returns a struct device* and I'm using that to make the device group, the struct kobject* that is coming into pxis_show is the member of the device structure made by device_create. If this is true, then I should be able to stuff some private data into that object and use it when the /sys files are accessed. However, when the lines of code marked above dereference the p member I get dereferencing pointer of incomplete type from gcc. I've determined that it's the struct device_private member of struct device that is incomplete but why? Is there a different structure I should be using? This seems to be something truly internally by the kernel.
For assign private data for device, you need to use void *drvdata parameter to device_create(). After creation, data can be accessed via dev_get_drvdata(pdev).
struct device_private is internal for device implementation. From description of this structure (drivers/base/base.h):
Nothing outside of the driver core should ever touch these fields.
I'm studying about Linux kernel and I have a problem.
I see many Linux kernel source files have current->files. So what is the current?
struct file *fget(unsigned int fd)
{
struct file *file;
struct files_struct *files = current->files;
rcu_read_lock();
file = fcheck_files(files, fd);
if (file) {
/* File object ref couldn't be taken */
if (file->f_mode & FMODE_PATH ||
!atomic_long_inc_not_zero(&file->f_count))
file = NULL;
}
rcu_read_unlock();
return file;
}
It's a pointer to the current process (i.e. the process that issued the system call).
On x86, it's defined in arch/x86/include/asm/current.h (similar files for other archs).
#ifndef _ASM_X86_CURRENT_H
#define _ASM_X86_CURRENT_H
#include <linux/compiler.h>
#include <asm/percpu.h>
#ifndef __ASSEMBLY__
struct task_struct;
DECLARE_PER_CPU(struct task_struct *, current_task);
static __always_inline struct task_struct *get_current(void)
{
return percpu_read_stable(current_task);
}
#define current get_current()
#endif /* __ASSEMBLY__ */
#endif /* _ASM_X86_CURRENT_H */
More information in Linux Device Drivers chapter 2:
The current pointer refers to the user process currently executing. During the execution of a system call, such as open or read, the current process is the one that invoked the call. Kernel code can use process-specific information by using current, if it needs to do so. [...]
Current is a global variable of type struct task_struct. You can find it's definition at [1].
Files is a struct files_struct and it contains information of the files used by the current process.
[1] http://students.mimuw.edu.pl/SO/LabLinux/PROCESY/ZRODLA/sched.h.html
this is ARM64 definition. in arch/arm64/include/asm/current.h, https://elixir.bootlin.com/linux/latest/source/arch/arm64/include/asm/current.h
struct task_struct;
/*
* We don't use read_sysreg() as we want the compiler to cache the value where
* possible.
*/
static __always_inline struct task_struct *get_current(void)
{
unsigned long sp_el0;
asm ("mrs %0, sp_el0" : "=r" (sp_el0));
return (struct task_struct *)sp_el0;
}
#define current get_current()
which just use the sp_el0 register. As the pointer to current process's task_struct
So when I call an ioctl on a device, with an ioctl number, how does it know which function to call?
The ioctl(2) enters via the fs/ioctl.c function:
SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
{
struct file *filp;
int error = -EBADF;
int fput_needed;
filp = fget_light(fd, &fput_needed);
if (!filp)
goto out;
error = security_file_ioctl(filp, cmd, arg);
if (error)
goto out_fput;
error = do_vfs_ioctl(filp, fd, cmd, arg);
out_fput:
fput_light(filp, fput_needed);
out:
return error;
}
Note that there is already a filedescriptor fd associated. The kernel then calls fget_light() to look up a filp (roughly, file pointer, but don't confuse this with the standard IO FILE * file pointer). The call into security_file_ioctl() checks whether the loaded security module will allow the ioctl (whether by name, as in AppArmor and TOMOYO, or by labels, as in SMACK and SELinux), as well as whether or not the user has the correct capability (capabilities(7)) to make the call. If the call is allowed, then do_vfs_ioctl() is called to either handle common ioctls itself:
switch (cmd) {
case FIOCLEX:
set_close_on_exec(fd, 1);
break;
/* ... */
If none of those common cases are correct, then the kernel calls a helper routine:
static long vfs_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
{
int error = -ENOTTY;
if (!filp->f_op || !filp->f_op->unlocked_ioctl)
goto out;
error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
if (error == -ENOIOCTLCMD)
error = -EINVAL;
out:
return error;
}
Drivers supply their own .unlocked_ioctl function pointer, like this pipe implementation in fs/pipe.c:
const struct file_operations rdwr_pipefifo_fops = {
.llseek = no_llseek,
.read = do_sync_read,
.aio_read = pipe_read,
.write = do_sync_write,
.aio_write = pipe_write,
.poll = pipe_poll,
.unlocked_ioctl = pipe_ioctl,
.open = pipe_rdwr_open,
.release = pipe_rdwr_release,
.fasync = pipe_rdwr_fasync,
};
There's a map in the kernel. You can register your own ioctl codes if you write a driver.
Edit: I wrote an ATA over Ethernet driver once and implemented a custom ioctl for tuning the driver at runtime.
A simplified explanation:
The file descriptor you pass to ioctl points to the inode structure that represents the device you are going to ioctl.
The inode structure contains the device number dev_t i_rdev, which is used as an index to find the device driver's file_operations structure. In this structure, there is a pointer to the ioctl function defined by the device driver.
You can read Linux Device Drivers, 3rd Edition for a more detailed explanation. It may be a bit outdated, but a good read nevertheless.
I have a linux kernel module that needs to find the speed of a given network interface (i.e. "eth0"). For linux 2.6.31 how would I find the speed (configured/negotiated)?
Every network driver has a "ethtool" implementation for such features. But you probably need a generic function that can give you the speed for a generic netdev struct. You can have a look at net/core/net-sysfs.c and see how it implements the /sys/class/net interface. For example :
static ssize_t show_speed(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct net_device *netdev = to_net_dev(dev);
int ret = -EINVAL;
if (!rtnl_trylock())
return restart_syscall();
if (netif_running(netdev) &&
netdev->ethtool_ops &&
netdev->ethtool_ops->get_settings) {
struct ethtool_cmd cmd = { ETHTOOL_GSET };
if (!netdev->ethtool_ops->get_settings(netdev, &cmd))
ret = sprintf(buf, fmt_dec, ethtool_cmd_speed(&cmd));
}
rtnl_unlock();
return ret;
}