linux-device-driver

问题 I have written basic char driver. Registration of char device with kernel has been done using cdev_alloc, cdev_init, cdev_add. Major = 117, Minor = 1. cdev_add function retrun success. I am trying to check whether char device created or not. I dont find any device under /dev/ or /dev/char with major no 117. register_chrdev is not going to be use in the latest kernel, where we give NAME. but cdev_add perform char device registration with kernel using major number only. I am confused with the

问题 I am toggling the input into a GPIO line on my BeagleBone from high to low every 500 ms using an Atmel uC. I have registered a handler for this in my Linux Kernel Module, but the handler is not being called for some reason. My module code is - #define GPIO 54 #define GPIO_INT_NAME "gpio_int" #define GPIO_HIGH gpio_get_value(GPIO) #define GPIO_LOW (gpio_get_value(GPIO) == 0) short int irq_any_gpio = 0; int count =0; enum { falling, rising } type; static irqreturn_t r_irq_handler(int irq, void

问题 So I'm working my way through kernel driver programming, and currently I'm trying to build a simple data transfer between application and kernel driver. I am using simple character device as a link between these two, and I have succeeded to transfer data to driver, but I can't get meaningful data back to user space. Kernel driver looks like this: #include <linux/init.h> #include <linux/module.h> #include <linux/kernel.h> /* printk() */ #include <linux/errno.h> /* error codes */ #include

问题 I was just reading The Linux Kernel Module Programming Guide and and got stuck on character device drivers example. Makefiles for previous examples were provided, but not for this one, so I'm trying to make one: obj-m += chardev.o all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules clean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean The output I'm getting is: maciej@jadwiga:~/Projects/os/chardev$ make make -C /lib/modules/2.6.26-2-686/build M=/home/maciej

问题 In a linux device driver, creating sysfs attributes in probe is way too racy--specifically, it experiences a race condition with userspace. The recommended workaround is to add your attributes to various default attribute groups so they can be automatically created before probe. For a device driver, struct device_driver contains const struct attribute_group **groups for this purpose. However, struct attribute_group only got a field for binary attributes in Linux 3.11. With older kernels

问题 I'm doing some edits to an input device driver in an android kernel. This device has a limited range of keybits and evbits enabled. What I want to do is to create a new /dev/input event node that is not related to any physical device, with more keybits and evbits enabled, so that I can send real input signals from the physical driver to the userspace, in the userspace I listen to them and when received I can inject input events to the "virtual" driver writing to its event node. Does linux

问题 We have an embedded system where a memory mapped device is connected, and an ARM CPU runs Linux. The device is located at address 0x40400000 and occupies a megabyte (most of it is not backed by an actual memory, but the address space is mapped to the device anyway). We currently don't have a device driver for this device. In the device there is a special read-only register (called CID) at address 0x404f0704 . This register contains the value CID = 0x404 . I am trying to read this register

问题 In linux device driver development, the file_operations structure uses "struct module *owner". What is the use of this structure when we always initialize it with THIS_MODULE ? When can this field be set to NULL? 回答1: this field tells who is owner of struct file_operations. This prevents module to get unloaded when it is in operation. When initialized with THIS_MODULE current module holds the ownership on it 回答2: Minimal runnable example Whenever you create a kernel module, the kernel's build

问题 I'm a noob to Linux device drivers so please bear with me. I'm trying to implement a i2c driver (client). It's at the point where I can insmod , .probe gets called (because of device-tree entries) and in the .probe I can read/write to the device. Great. However I need to be able to initiate read/writes from userspace to the driver. In order to do this, should an i2c driver be shaped like any other char device driver? Meaning having a file_operations struct so userspace can open , close , read

问题 I need to control an HCI device directly without the Linux drivers/kernel interfering. For example, when creating an LE connection to a peripheral, the driver is independently sending an "LE Connection Update" command which I would like to avoid. I though of two approaches to resolve this: Configure the bluetooth drivers to somehow disable interference with the HCI device (similar to the -r flag on hciattach), then control the HCI device using a regular AF_BLUEOOTH socket. Disable this